3

Our OpenLDAP Servers run version on EL6. OpenLDAP is built against the Mozilla Network Security Services (NSS) libraries. Our LDAP clients come from a wide variety of Unix & Linux systems.

We are unable to get OpenLDAP connections working for clients or replication when we use our preferred TLS ciphers.

For example, if we use Red Hat's Strongest available ciphers only list, such as this:

# /etc/openldap/slapd.conf
TLSProtocolMin 3.2
TLSCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!EDH:!EXP:!SSLV2:!eNULL

Client connections fail, because they do not meet our ACL requirement for a minimum Security Strength Factor (SSF):

slapd[22887]: conn=1022 fd=20 ACCEPT from IP=192.168.100.101:35936 (IP=192.168.100.100:636)
slapd[22887]: conn=1022 fd=20 TLS established tls_ssf=128 ssf=128
...
slapd[22887]: <= check a_authz.sai_ssf: ACL 256 > OP 128

How can I see which cipher is being used for this connection so that I can eliminate it from the list?

If we disable the cipher list and use the defaults provided by OpenLDAP + NSS, it works:

# /etc/openldap/slapd.conf
TLSProtocolMin 3.2
# TLSCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!EDH:!EXP:!SSLV2:!eNULL


slapd[6020]: conn=1003 fd=20 ACCEPT from IP=192.168.100.101:35936 (IP=192.168.100.100:636)
slapd[6020]: conn=1003 fd=20 TLS established tls_ssf=256 ssf=256

However, the default list is unacceptable because it includes some weak ciphers which our security team doesn't want, such as RC4-SHA & RC4-MD5 ciphers.

We are aware that EL6 is becoming EOL by the end of the year. That's a different problem.

Stefan Lasiewski
  • 23,667
  • 41
  • 132
  • 186
  • (1) wireshark or tshark, or if not available/authorized either `tcpdump -x port 636` (probably also `-n`, maybe `-i`) and look in server first flight at 0x70 (assuming no extensions in the TCP header) for 2, or `tcpdump -wfile port 636` and move the file to somewhere you _do_ have wireshark/tshark (2) I don't know exactly how the OpenSSL-NSS translation works, but in OpenSSL `DEFAULT:!RC4` would do what you want. – dave_thompson_085 Jun 11 '20 at 06:17
  • Thanks, that's what I ended up doing. Of all things, I had to disable AES_128 using `!AES128`. RC4, MD5, etc. were already disabled by the OS, apparently. – Stefan Lasiewski Jun 12 '20 at 22:53

1 Answers1

2

I wasn't able to do this directly with tcpdump or tshark on the node. What I had to do was to capture tcpdump on the machine, transfer the data to my laptop and then run a modern version of Wireshark per https://security.stackexchange.com/questions/52150/identify-ssl-version-and-cipher-suite

Another very helpful command was to use nmap's scripts to enumerate the ciphers:

$ nmap --script ssl-enum-ciphers -p 636 ldap.example.org -Pn


PORT    STATE SERVICE
636/tcp open  ldapssl
| ssl-enum-ciphers: 
...
|   TLSv1.2
|     Ciphers (16)
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA
|       TLS_RSA_WITH_AES_128_CBC_SHA
|       TLS_RSA_WITH_AES_128_CBC_SHA256
|       TLS_RSA_WITH_AES_128_GCM_SHA256
|       TLS_RSA_WITH_AES_256_CBC_SHA
|       TLS_RSA_WITH_AES_256_CBC_SHA256
|       TLS_RSA_WITH_AES_256_GCM_SHA384
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA


Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds

Those AES_128 ciphers are causing my problem, and so I disabled them by adding it to the list of excluded ciphers:

TLSCipherSuite HIGH:!LOW:!MEDIUM:!RC4:HIGH:!MD5:!EDH:!EXP:!SSLV2:!eNULL:!AES128
Stefan Lasiewski
  • 23,667
  • 41
  • 132
  • 186