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

LDAP SSL decrypt issue

0

Hi everybody,

I'm trying to debug LDAP SSL communication and experience a problem with SSL decryption. I start my capturing before any handshake so I'm able to see the whole SSL handshake. But after that an application establishes another session which is a short version with ClientHello->ServerHello, ChangeCipherSpec, Finished. And after that handshake I'm unable to decode client packets while server are still readable.

Could you advise me on a way to resolve that issue so that I could decode all the packets after the second handshake?

Thank you!

asked 24 Sep '13, 06:16

PhilippGrigoryev's gravatar image

PhilippGrigo...
11113
accept rate: 0%


One Answer:

0

Does the second SSL handshake use a "TLS session tickets" that was sent in the first SSL handshake? Wireshark does not (yet) supoort session tickets for decryption. You could disable session tickets and use SSL session-id's instead.

If that's not the case, are you able to post both SSL handshakes to www.cloudshark.org?

answered 30 Sep '13, 13:38

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Well, I figured out that the problem starts actually after the malformed packet. It's a frame #27 (packet which Wireshark shows as Application Data[Malformed Packet]). I uploaded the whole session at http://www.cloudshark.org/captures/2d105476040d

and that's a fragment from a SSL debug file starting from a handshake frame. And here I can see some decrypted data from Malformed Packet but just here, not in Wireshark. SSL Dump on PasteBin

(30 Sep '13, 16:23) PhilippGrigo...

(I converted your "answer" to a "comment", please see the FAQ)

The capture file and the ssl debug file do not seem to match. Could you decrypt the file you posted on cloudshark again (start with an empty ssl debug file) and post the ssl-debug output again?

(01 Oct '13, 00:12) SYN-bit ♦♦

I am facing the same issue, after a malformed packet is seen from the client, all the client data are no longer decoded by wireshark

(09 Jan '14, 03:10) MSK