I'm trying to decode LDAP traffic over SSL to troubleshoot an issue we're having. I've setup the SSL protocol properties with the PFX file that has the private key in it and I've decoded both source 636 and dest 636 as LDAP, but it never wants to actually decode anything and just leaves everything as TCP. I'm running Wireshark 1.6.5. I know that I've done this in the past with an earlier version of Wireshark. If I leave it un-decoded, it'll show the data packets as TLSv1 and indicate that there is encrypted LDAP traffic in the packet, so I'm not sure what the deal is, but I'm obviously missing something. Edit: debug file moved from "answer" to question: asked 27 Mar ‘12, 06:55  infinity9999 edited 27 Mar ‘12, 08:49  grahamb ♦ |
One Answer:
Have you reviewed the SSL page on the wiki? That states that the key should be in PEM format and gives some conversion recipes, and also discusses LDAP but I don't think that info is applicable in your case. Using the SSL dissector preferences you can also set an SSL Debug file. Doing that and posting the contents here may help us to answer your question. answered 27 Mar '12, 07:38 grahamb ♦ showing 5 of 15 show 10 more comments |
Yes, I've read it. I've tried both PEM and PFX (1.6.5 allows PFX or P12 with the password). I just tried with 1.4.11 and that didn't work either.
The debug shows this (snippet from the top), which appears to me to be working as it should (i.e. it can read in the key and appears to be able to figure out which packets to dissect):
ssl_association_remove removing TCP 636 - ldap handle 0000000003DAB350 ssl_init keys string: 1.1.1.1,636,ldap,c:\server.pem ssl_init found host entry 1.1.1.1,636,ldap,c:\server.pem ssl_init addr '1.1.1.1' port '636' filename 'c:\server.pem' password(only for p12 file) '(null)' Private key imported: KeyID 08:c7:ea:d2:... ssl_init private key file c:\server.pem successfully loaded association_add TCP port 636 protocol ldap handle 0000000003DAB350
dissect_ssl enter frame #3 (first time) ssl_session_init: initializing ptr 00000000086A1F48 size 672 conversation = 00000000086A1CE8, ssl_session = 00000000086A1F48 record: offset = 0, reported_length_remaining = 133 dissect_ssl3_record found version 0x0301 -> state 0x10 dissect_ssl3_record: content_type 23 decrypt_ssl3_record: app_data len 128, ssl state 0x10 association_find: TCP port 65250 found 0000000000000000 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available association_find: TCP port 65250 found 0000000000000000 association_find: TCP port 636 found 000000004E9C5230
dissect_ssl enter frame #4 (first time) conversation = 00000000086A1CE8, ssl_session = 00000000086A1F48 record: offset = 0, reported_length_remaining = 53 dissect_ssl3_record: content_type 23 decrypt_ssl3_record: app_data len 48, ssl state 0x10 association_find: TCP port 636 found 000000004E9C5230 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available association_find: TCP port 636 found 000000004E9C5230
I've converted your "answer" to a comment and (due to the comment length limits) copied the debug output into the question and formatted it as "code".
I'm wondering if it's becuase I'm not seeing the SSL handshake in my trace. Does the handshake need to be in the trace for it to actually decode things?
Yes. That is where the session key is derived from the master key to use during the subsequent data exchanges.
I'm looking in my trace and I do see handshakes occuring. Do I need to decode things from the handshake packet itself? I thought you could just decode from any packet that was talking on that port.
Does it make a difference that it's LDAP against Active Directory?
Re needing the handshake. Yes that must be present in the trace. What do you mean by "decode from the handshake packet itself"? The debug log should show the info from the handshakes and the calculation of the session key.
Re LDAP against AD. Not that I know of.
See also this question which was also about AD LDAP over SSL. They had issues with the key exchange cipher that prevented decryption.
I do show this in the debug log, but the packet says it's using Cipher Suite TLS_RSA_WITH_AES_128_CBC_SHA (0x002f):
Also, re: the decode packet, disregard that. That was part of a doc that we had used that described decrypting SSL on non-standard ports. My brain hasn't been all there recently.
That is the first part of the key exchange that has the server hello and certificate, the next part is the client key exchange, the change cipher spec and handshake finished. That is the key frame you need to inspect in the debug log.
The snakeoil demo on the SSL wiki page uses TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) which is stronger than you are using, so no worries there.
You need to inspect (or post) the next part of the debug log that shows the session key generation.
Did more digging and testing. I think the issue lies that the server hello packet in response to the client request doesn’t list the certificate in it, only the change cipher spec and encrypted handshake. The handshake occurs for the application, but the cert is never passed along, so wireshark probably can’t figure out what to decrypt.
And more digging is uncovering some more info. Basically the issue we’re investigating is what looks like a complete network drop for about a minute on the server end. In the trace, we can see all the resets followed by normal activity. However after the resets go through, I’m able to decrypt at the least the bind traffic. It looks like there’s more, but it’s not decrypting. So, I’m thinking that we have something like persistent connections that are just maintaining themselves without doing handshakes with the certs or something so I can’t decrypt prior to the resets.
The SSL client and server can cache the keying information for each session. This will prevent a new connection from doing the CPU expensive key exchange.
As you already noticed, the “Certificate” message is missing in those cases. But more importantly, the “ClientKeyExchange” message is missing, it is this message that contains the keying material (encrypted with the public key from the Certificate).
Wireshark uses the private key from the server to decrypt the “ClientKeyExchange” to get to the keying material for that particular SSL session. Without the keying material, no SSL decryption!