CodeShare
Have some code. Share some code.
cancel
Showing results for 
Search instead for 
Did you mean: 
Jer-O
Cirrus
Cirrus

Problem this snippet solves:

This procedure allows you to decrypt a tcpdump made on the F5 without requiring access to the key file. Despite multiple F5 pages that claim to document this procedure, none of them worked for me. This solution includes the one working iRule I found, trimmed down to the essentials. The bash command is my own, which generates a file with all the required elements from the LTM log lines generated by the iRule, needed to decrypt the tcpdump in Wireshark 3.x.

How to use this snippet:

Upgrade Wireshark to Version 3+.

Apply this iRule to the virtual server targeted by the tcpdump:

rule sessionsecret {
  when CLIENTSSL_HANDSHAKE {
    log local0.debug "CLIENT_RANDOM [SSL::clientrandom] [SSL::sessionsecret]"
    log local0.debug "RSA Session-ID:[SSL::sessionid] Master-Key:[SSL::sessionsecret]"
  }
  when SERVERSSL_HANDSHAKE {
    log local0.debug "CLIENT_RANDOM [SSL::clientrandom] [SSL::sessionsecret]"
    log local0.debug "RSA Session-ID:[SSL::sessionid] Master-Key:[SSL::sessionsecret]"
  }
}

Run tcpdump on the F5 using all required hooks to grab both client and server traffic.

tcpdump -vvni 0.0:nnnp -s0 host <ip> -w /var/tmp/`date +%F-%H%M`.pcap

Conduct tests to reproduce the problem, then stop the tcpdump  (Control C) and remove the iRule from the virtual server.

Collect the log lines into a file.

cat /var/log/ltm | grep -oe "RSA Session.*$" -e "CLIENT_RANDOM.*$" > /var/tmp/pms

Copy the .pcap and pms files to the computer running Wireshark 3+.

Reference the "pms" file in "Wireshark > Preferences > Protocols > TLS > (Pre)-Master-Secret log filename" (hence the pms file name).

Ensure that Wireshark > Analyze > Enabled Protocols > "F5 Ethernet trailer" and "f5ethtrailer" boxes are checked.

Open the PCAP file in Wireshark; it will be decrypted.

IMPORTANT TIP: Decrypting any large tcpdump brings a workstation to its knees, even to the point of running out of memory. A much better approach is to temporarily move the pms file, open the tcpdump in its default encrypted state, identify the problem areas using filters or F5 TCP conversation and export them to a much smaller file. Then you can move the pms file back to the expected location and decrypt the smaller file quickly and without significant impact on the CPU and memory.

Code :

Please refer to the "How to use this Code Snippet" section above. This procedure was successfully tested in 12.1.2 with a full-proxy virtual server.

Tested this on version:

12.1
Comments
Squeak
Cirrus
Cirrus

The snippet also works on 13.1.x

 

Thanks for share.

Jer-O
Cirrus
Cirrus

Squeak, thanks for confirming success on 13 and taking the time to comment. Mind giving it a thumbs up? Cheers!

Squeak
Cirrus
Cirrus

 Of course, I´ll give you two thumbs up 🙂

 

Cheers

Jer-O
Cirrus
Cirrus

LOL, deeply appreciated, and thank you! Just used this in a prod intermittent outage investigation. It was instrumental in the root cause analysis.

I retested the shared procedure in the lab in versions 12.1.2 HF2, 13.1.1.5 and 14.1.2, all of which were successful.

 

Congratulations on the article. 🙂

 

In the previously applied test was on a production VS, I restricted access to the client IP only, because this VS has more than 5k connections.

 

Great article you wrote. Cheers! 👊

Jer-O
Cirrus
Cirrus

, thanks for the update!

Jer-O
Cirrus
Cirrus

Added an important tip at the bottom of the "How to use..." section.

Version history
Last update:
‎18-Oct-2019 21:15
Updated by:
Contributors