This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

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:

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

asked 27 Mar '12, 06:55

infinity9999's gravatar image

infinity9999
1112
accept rate: 0%

edited 27 Mar '12, 08:49

grahamb's gravatar image

grahamb ♦
19.8k330206


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.

permanent link

answered 27 Mar '12, 07:38

grahamb's gravatar image

grahamb ♦
19.8k330206
accept rate: 22%

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

(27 Mar '12, 08:34) infinity9999

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".

(27 Mar '12, 08:51) grahamb ♦

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?

(27 Mar '12, 09:20) infinity9999

Yes. That is where the session key is derived from the master key to use during the subsequent data exchanges.

(27 Mar '12, 09:24) grahamb ♦

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.

(27 Mar '12, 09:28) infinity9999

Does it make a difference that it's LDAP against Active Directory?

(27 Mar '12, 09:40) infinity9999

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.

(27 Mar '12, 09:49) grahamb ♦

See also this question which was also about AD LDAP over SSL. They had issues with the key exchange cipher that prevented decryption.

(27 Mar '12, 09:58) grahamb ♦

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):

    dissect_ssl enter frame #172799 (first time)
  conversation = 000000000D954BE8, ssl_session = 000000000D9550B0
  record: offset = 0, reported_length_remaining = 145
dissect_ssl3_record found version 0x0301 -> state 0x11
dissect_ssl3_record: content_type 22
decrypt_ssl3_record: app_data len 81, ssl state 0x11
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available
dissect_ssl3_handshake iteration 1 type 2 offset 5 length 77 bytes, remaining 86 
dissect_ssl3_hnd_hello_common found SERVER RANDOM -> state 0x13
ssl_restore_session can't find stored session
dissect_ssl3_hnd_srv_hello found CIPHER 0x002F -> state 0x17
dissect_ssl3_hnd_srv_hello trying to generate keys
ssl_generate_keyring_material not enough data to generate key (0x17 required 0x37 or 0x57)
dissect_ssl3_hnd_srv_hello can't generate keyring material
  record: offset = 86, reported_length_remaining = 59
dissect_ssl3_record: content_type 20
dissect_ssl3_change_cipher_spec
packet_from_server: is from server - TRUE
ssl_change_cipher SERVER
  record: offset = 92, reported_length_remaining = 53
dissect_ssl3_record: content_type 22
decrypt_ssl3_record: app_data len 48, ssl state 0x17
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available
dissect_ssl3_handshake iteration 1 type 254 offset 97 length 16114481 bytes, remaining 145 
(27 Mar '12, 10:59) infinity9999

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.

(27 Mar '12, 11:08) infinity9999

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.

(27 Mar '12, 13:45) grahamb ♦

dissect_ssl enter frame #172811 (first time)
  conversation = 000000000D954BE8, ssl_session = 000000000D9550B0
  record: offset = 0, reported_length_remaining = 6
dissect_ssl3_record: content_type 20
dissect_ssl3_change_cipher_spec
packet_from_server: is from server - FALSE
ssl_change_cipher CLIENT

dissect_ssl enter frame #172812 (first time)
  conversation = 000000000D954BE8, ssl_session = 000000000D9550B0
  record: offset = 0, reported_length_remaining = 53
dissect_ssl3_record: content_type 22
decrypt_ssl3_record: app_data len 48, ssl state 0x17
packet_from_server: is from server - FALSE
decrypt_ssl3_record: using client decoder
decrypt_ssl3_record: no decoder available
dissect_ssl3_handshake iteration 1 type 227 offset 5 length 15358476 bytes, remaining 53 
(27 Mar '12, 14:26) infinity9999

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.

(29 Mar '12, 11:52) infinity9999

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.

(29 Mar '12, 13:45) infinity9999
1

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!

(30 Mar '12, 01:04) SYN-bit ♦♦
showing 5 of 15 show 10 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×319
×89
×24

question asked: 27 Mar '12, 06:55

question was seen: 9,298 times

last updated: 30 Mar '12, 01:04

p​o​w​e​r​e​d by O​S​Q​A