I recently needed to restrict the list of ciphers that my LDAP server allowed. However, I wanted to make sure that my LDAP clients (many not under my control) would still be able to negotiate a cipher after I made the change. I was able to capture SSL/TLS cipher usage and parse the log into a report.

First, capture the SSL/TLS handshakes from the server using tshark (wireshark):

tshark -l -f ‘tcp port 389’ -2R ‘ssl.handshake.type==2 or ssl.handshake.type==1’ -T fields -e ssl.handshake.type -e ssl.record.version -e ssl.handshake.version -e ssl.handshake.ciphersuite -e ssl.handshake.cipherspec -e ip.src -e ip.dst > ldap-cipher-track1.log

I ran this a second time for port 636 into a separate file so that I could identify which clients were using LDAP vs LDAPS.

Log entries look like:

1 0x0301 0x0301 0xc009,0xc013,0x002f,0xc004,0xc00e,0x0033,0x0032,0xc008,0xc012,0x000a,0xc003,0xc00d,0x0016,0x0013,0xc007,0xc011,0x0005,0xc002,0xc00c,0x0004,0x00ff 128.193.4.147 128.193.4.137
2,11,12,14 0x0301 0x0301 0xc011 128.193.4.137 128.193.4.147

Lines that begin with “1” are the Client Hello. Lines that begin with “2” are the Server Hello. The Client Hello includes the list of ciphers that the client supports. The Server Hello tells the client which cipher the server selected. Note: We don’t need the server’s private key because we are not decrypting anything.

After we have the log file, we parse it with Perl to report the following:

1. Client ciphers offered – a summarized list of all the ciphers offered
2. Ciphers selected – a summarized list of the ciphers actually selected
3. Clients using weak ciphers – a list of clients by IP with the weak ciphers they used and a list of strong ciphers they support
4. Clients that don’t support any of our enabled ciphers – any clients that won’t support our desired list of enabled ciphers

Example output:

Client ciphers offered:
TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
TLS_RSA_WITH_RC4_128_MD5 (0x0004)
TLS_RSA_WITH_RC4_128_SHA (0x0005)
…
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031)
Ciphers selected:
TLS_RSA_WITH_RC4_128_MD5 (0x0004)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Clients using weak ciphers:

10.193.14.179:
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Strong Ciphers Offered: 0x000a 0x0013 0x0016 0x002f 0x0032 0x0033 0x00ff 0xc003 0xc004 0xc008 0xc009 0xc00d 0xc00e 0xc012 0xc013

Clients that don’t support any of our enabled ciphers:

The Perl scripts and a required CSV file are available at:
http://people.oregonstate.edu/~morgan/ciphers/

I stumbled across an interesting problem… If you run a Tomcat SSL web server and have Chrome browsers as clients, you may see errors in Chrome. These errors are not the fault of Tomcat, but they are a bug in older versions of the Java JDK which Tomcat uses for SSL. Costin Manolache’s blog post explains it fairly well. The bug in JSSE was fixed in JDK 6u12.

Why are there two different Thawte Premium Server CA certificates out there?
Thawte distributes one at their root certificates web site:

Serial Number: 36 12 22 96 c5 e3 38 a5 20 a1 d2 5f 4c d7 09 54
Valid From: Wednesday, July 31, 1996
Valid to:  Friday, January 01, 2021
Certificate SHA1 Fingerprint: e0 ab 05 94 20 72 54 93 05 60 62 02 36 70 f7 cd 2e fc 66 66
Key Size: RSA(1024 Bits)

but there is a different version distributed with Redhat, Debian, Firefox, and OS X:

Serial Number: 1 (0x1)
Validity
     Not Before: Aug  1 00:00:00 1996 GMT
     Not After : Dec 31 23:59:59 2020 GMT
SHA1 Fingerprint=62:7F:8D:78:27:65:63:99:D2:7D:7F:90:44:C9:FE:B3:F3:3E:FA:9A

If I build a certificate chain for an SSL web server using the one from Thawte’s web site, OS X says the site uses an invalid certificate.

*** Update ***

There ARE 2 different Thawte Premium Server CA certificates:

MD5-signed
SHA1-signed

We’ll see if they tell me why they did that…

*** Update 2 ***

Thawte was required by the browser vendors to sign their CA certs with SHA1 instead of MD5. See here: https://search.thawte.com/support/ssl-digital-certificates/index?page=content&actp=CROSSLINK&id=AD221