I analyzed a file today regarding an SSL session (or at least attempt thereof). The fourth packet in line should be a Client Hello packet with all the necessary SSL data underneath. But it wasn't. It only showed a PSH,ACK type of packet. When comparing this to a similar file (in which the SSL sessions successfully initiated) I did see the Client Hello packet. Although the size of the two packets was exactly the same, one showed as a Client Hello packet, the other as a regular TCP packet. Even when specifically specifying the packet as being part of the SSL protocol (right click > decode as), it refused to show me more info in the details pane. I only got the issue resolved by isolating this one packet in a separate file and then opening it again. Only then was it shown as an SSL packet and could I see the details. I added a screenshot to avoid heavy scrubbing. Can anyone give me an explanation as to why Wireshark shows this behavior? It must have something to do with the fact the SSL handshake failed.
asked 15 Feb '16, 08:23  JoepMeloen86 |
One Answer:
answered 17 Feb '16, 08:36 JoepMeloen86 Looks OK to me using a build from master, so probably fixed. Try a newer build from automated downloads. (17 Feb '16, 09:02) grahamb ♦ According to bug report it might be caused by the followed up HTTP packet from a proxy server. A suggested downgrade back to 1.12 resolves the issue but doesn't display the HTTP packet anymore (which it was displaying in 2.0.1) Anyway, for completeness I tested with the latest build from master as you suggested but the issue persists. I will wait for the bug report conclusion (17 Feb '16, 23:29) JoepMeloen86 |
Assuming that SSL works in general, anonymizing the capture by just substituting the IP addresses should be secure enough if you wouldn't publish any key material, and would allow much better analysis.
Without access to the capture, I would suggest that you export to a new file all frames starting from frame 149 in the current one (the first SYN packet), and to another new file, all frames up to frame 152. Opening both these new files should answer the question whether Wireshark has problems to properly decode the packet due to something it can see before that packet (like other TCP packets using the same pair of sockets), or because the SSL handshake has failed after that packet.
It may turn out that it is worth opening a bug on Wireshark bugzilla. Posting the capture file there would be necessary but you can mark it as a "private attachment" accessible only to the core developers.
The problem is the same with packet 149 and up. The problem is gone when exporting packet 152 and lower.
So it seems that as soon as the SSL handshake is unsuccessful, it doesn't classify it as SSL and is unable to.
Do you still suggest to post it on wireshark bugzilla ?
Yes, as it is the most reliable way to inform the respective developer about the bug.