Forum Discussion
CirrostratusSSL Decryption with Wireshark - Cached Certificate?
* vip IP
* VIP HTTPS port number (typically 443)
* protocol (typically "http")
* SSL private key on local filesystem (from /config/ssl/ssl.key on LTM)
I've always had hit-and-miss success (more misses than hits) decrypting HTTPS in this manner. More recently, I've had no success at all. I viewed a Wireshark video on SSL and looked closely at the SSL debug log in Wireshark, and both seem to point to the fact that I haven't captured the "full" SSL key transfer:
"ssl_generate_keyring_material not enough data to generate key"
I'm not entirely sure about this, but my understanding was that an LTM can cache the SSL certificate? That might explain why I can't seem to capture the entire key transfer. And if that's the case, is there a propery in the SSL client profile I can adjust to force the LTM to always perform a full certificate transfer?
Maybe someone could clarify if I'm off-base?
hoolioHi SMP,
As you say, in order for the SSL decryption to work, you have to capture the initial handshake. If you have control over the client, it would be better to clear the SSL cache on the client versus LTM. This will force the client to negotiate a new SSL session. Your decryption should then succeed. In IE, you can go to Tools | Options | Content | Clear SSL state. For Firefox, I think it's active logins that you can clear using Ctrl+Shift + Delete.
If you don't have control over the client, I think a 'b load' will clear the SSL cache on LTM. It would be a significant hit if you prevented LTM from caching SSL sessions, as I believe the initial SSL handshake is the most computationally expensive operation in the SSL conversation. If you still wanted to do this, I think you could set the client SSL profile's cache size to 0 sessions.
Aaron
smp_86112That's what I thought too, but had some difficulty. However my methodology must have been incorrect somewhere, because I just tried it again and it worked. I captured an SSL session with tcpdump, configured Wireshark with the private key, and validated unsuccessful decryption with the error I have already noted. Then I changed the Cache Size value in the Client SSL Profile that is applied to the VS from the default (20000) to zero, and did another capture. This time Wireshark was was able to successfully decrypt.
Thanks for confirming my understanding hoolio. This is a great tip if you need to decrypt in a pinch without having access to the client.
prashanth_12571Nimbostratus
I did that on the version 11 it did not work. The packet capture was using the -s0 option- nitass
Employee
I did that on the version 11 it did not work. The packet capture was using the -s0 optionwhat cipher was it used? some cipher cannot be decrypted.
Important: Not all ciphers provide the ability to decrypt SSL traffic using a utility such as ssldump. Depending on the cipher negotiated, the ssldump utility may not be able to derive enough information from the SSL handshake and the server’s private key to decrypt the application data. Examples of such SSL ciphers would be the Diffie-Hellman Ephemeral (DHE) cipher suites and export-grade RSA cipher suites.sol10209: Overview of packet tracing with the ssldump utility
http://support.f5.com/kb/en-us/solutions/public/10000/200/sol10209.html - smp_86112Posted By prashanth on 07/02/2013 07:53 AM
I did that on the version 11 it did not work. The packet capture was using the -s0 optionYou 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").
