Forum Discussion
I did that on the version 11 it did not work. The packet capture was using the -s0 option
You did what, exactly?
As hoolio correctly stated, you must capture the entire SSL handshake in order for wireshark to decrypt it. There's a couple of ways I can think of to verify this. One is to use the display filter "ssl.handshake.type == 11". That should display packets that contain a certificate. If you don't see any packets (because they are all filtered out), then you don't have the full SSL handshake.
Two other ways involve looking at the first response packet sent by the server after the Client Hello. If you select this packet and change your Wireshark View to show Packet Details, then expand all of the the Secure Sockets Layer headers, you should find all the certificate details. You can also look for a heading labed "Session ID Length" - if that value is zero, it's a new SSL session. If the value is a long string of characters, then the SSL session is cached and you can't decrypt.
The third, and my preferred way, is to have a custom column (Field Type: Custom, Field Name: tcp.len) added to my Wireshark view. This column displays the number of TCP bytes contained in the packet. When the entire certificate is transmitted (meaning a full SSL handshake), the TCP length of this packet is typically 2000-3000 bytes in my environment. If the SSL session is cached (and wireshark can't decrypt), only the SSL Session ID is transmitted so the number of bytes is much smaller - typically 100-200 bytes.
Incidentally, this custom column trick is helpful in other ways. For example instead of me having to use a long filter when isolating a particular TCP conversation, I simply add a custom column (Field Type: Custom, Field Name: tcp.stream) to my wireshark view. Each TCP conversation is labeled with a "stream" number. So when you find an interesting packet in the Wireshark view, simply look at this custom column, denote the stream number, and use that as a filter (i.e. "tcp.stream eq 4").