Forum Discussion
SSL::sessionid returns the current connection's SSL session ID if it exists in the session cache.
A Cache Size setting of 0 disables SSL session caching for the profile, which means the Session ID will not be cached and the command will return a null string.
- Allwyn_MascarenDec 31, 2018Cirrus
Ahh ok but then I need to get the CLIENT_RANDOM from the pcap file and add it with the sessionsecre to create the SSL dump file right?
This is still not decrypting the pcap.
- DaveSJan 01, 2019Nimbostratus
I assume you're following the process outlined here:
K16700: Decrypting SSL traffic using the SSL::sessionsecret iRules command
Yes, you'll need to use the CLIENT_RANDOM option with the random byte string as the identifier and sessionsecret string for the master key string.
If there are multiple connections in the packet capture then you will need to look at all the client source ports used so that the Master Secret log file contains multiple lines, each with the random byte string with the matched key string. As noted in the steps, the syntax is important.
If you're still having issues with the decryption then enabling SSL debugging in Wireshark and looking at the output this produces should indicate what's going wrong.
- DaveS_377638Jan 01, 2019Cirrus
I assume you're following the process outlined here:
K16700: Decrypting SSL traffic using the SSL::sessionsecret iRules command
Yes, you'll need to use the CLIENT_RANDOM option with the random byte string as the identifier and sessionsecret string for the master key string.
If there are multiple connections in the packet capture then you will need to look at all the client source ports used so that the Master Secret log file contains multiple lines, each with the random byte string with the matched key string. As noted in the steps, the syntax is important.
If you're still having issues with the decryption then enabling SSL debugging in Wireshark and looking at the output this produces should indicate what's going wrong.
- Allwyn_MascarenJan 02, 2019Cirrus
Yes that's the KB article.
So I have to collect multiple client random strings and session ids? and put them in the ssldump file?
CLIENT_RANDOM 4ed16cd95ddf6c014af02dabc1fa07cedc50dc8c1b29cd5731d7a2fb1671884e 6ea721cbec21568788113ca69dcbc2a11a2757c47dd89650d2f2759347bf923eccb6793ffb3186608b32ecadc1fe3118 CLIENT_RANDOM 4ed16cd95ddf6c014af02dabc1fa07cedc50dc8c1b29cd5731d7a2fb1671884e 6ea721cbec21568788113ca69dcbc2a11a2757c47dd89650d2f2759347bf923eccb6793ffb3186608b32ecadc1fe3118 CLIENT_RANDOM 4ed16cd95ddf6c014af02dabc1fa07cedc50dc8c1b29cd5731d7a2fb1671884e 6ea721cbec21568788113ca69dcbc2a11a2757c47dd89650d2f2759347bf923eccb6793ffb3186608b32ecadc1fe3118
Something like this but will different strings, I am just using this as an example.
- Allwyn_MascarenJan 03, 2019Cirrus
I have the f5 auction site in my lab and i created a https vip for it with certificates from my CA.
Still when I do a pcap and enter a password i can see the password in the pcap with a simple edit -> find packet in wireshark.
And at the same time I can also see TLS application data encrypted packets. Why is this happening? How am I able to see the password even without adding any decryption keys to wireshark?
Further when I add decryption keys the TLS application data encrypted packets are all decrypted, which is fine but I don't get why is the password visible without the decryption keys.
- DaveSJan 03, 2019Nimbostratus
I see you have another question that's involving the same processes so if you're doing the tcpdump capture wireshark analysis on the same machine as you're doing client side capture and wireshark analysis then I can guess why there is some confusion.
If you have SSLKEYLOG set then Chrome or Firefox will start adding entries to the file for TLS connections. If Wireshark is configured for this as the (Pre)-Master-Secret log then it will be able to decrypt the browser traffic while the settings are in place.
It doesn't matter where the packet capture comes from, Wireshark will attempt to find any identifier in the (Pre)-Master-Secret log and decrypt the traffic with the matching session key. So, if you're using the browser, it doesn't matter if you're capturing locally or using tcpdump for this traffic on the LTM and pull the capture down and open with Wireshark, it will find matching client_random values and be able to decrypt this traffic.
The process mentioned applies for LTM side capture, which is why the (Pre)-Master-Secret log needs to be manually created. Also, it will track all the SSL handshakes, whereas doing it client side only will create entries for just the browser and not java for example, for which you will need to use a Java Agent library to create the log entries.
- DaveS_377638Jan 03, 2019Cirrus
I see you have another question that's involving the same processes so if you're doing the tcpdump capture wireshark analysis on the same machine as you're doing client side capture and wireshark analysis then I can guess why there is some confusion.
If you have SSLKEYLOG set then Chrome or Firefox will start adding entries to the file for TLS connections. If Wireshark is configured for this as the (Pre)-Master-Secret log then it will be able to decrypt the browser traffic while the settings are in place.
It doesn't matter where the packet capture comes from, Wireshark will attempt to find any identifier in the (Pre)-Master-Secret log and decrypt the traffic with the matching session key. So, if you're using the browser, it doesn't matter if you're capturing locally or using tcpdump for this traffic on the LTM and pull the capture down and open with Wireshark, it will find matching client_random values and be able to decrypt this traffic.
The process mentioned applies for LTM side capture, which is why the (Pre)-Master-Secret log needs to be manually created. Also, it will track all the SSL handshakes, whereas doing it client side only will create entries for just the browser and not java for example, for which you will need to use a Java Agent library to create the log entries.
- Allwyn_MascarenJan 06, 2019Cirrus
Well this was a little misunderstanding on my side, I was capture with -p and when I did a search string I was seeing the password from f5 -> client leg of the flow.
I got the decryption to work later by enabling cache and also using the sslkeylog file from windows.