Hi - I've been trying to decrypt an SSL stream from a single client to one of our servers. Since I was unable to decode it, I thought it may have been as a result of DH key negotiation, but the trace I took just seemed too odd. You can see that packet 11 is summarized by Wireshark (1.4.6) as 'Ignored Unknown Record' at the point where I would expect 'Server Hello' The capture was taken on the Linux box which acts as a load balancer in our network, so it's right bang in the middle of the data path between client and server. Commandline: Here is the capture: http://194.24.251.10/oddssl.cap asked 01 Jun '11, 15:03  gdhgdh edited 01 Jun '11, 15:09 |
One Answer:
You used a snaplength of 1500, while packets can be 1514 bytes (or 1518 when the FCS is not stripped by the NIC). As you can see in the frame-header, 14 bytes were lost, so Wireshark is not able to do reassembly. answered 01 Jun '11, 22:51  SYN-bit ♦♦ |
<blush> I feel very silly. Thank you for pointing the snaplen out.
FWIW my theory about DH key exchange was right, and now I have the proof. Trebles all round =)
No Worries, we all have our less ingenious moments ;-)
About the DH key exchange, you are indeed not able to decrypt them with the server key. However, Chrome and Firefox can now be built with SSL debugging on, so that it saves the pre-master secrets to file and you can import them in Wireshark.
Another possibility is to (temporarily) disable all DH cipers on the server side so that a non-DH gets chosen so you can do your troubleshooting on the decrypted traffic.