Decrypting tcpdumps in Wireshark without key files (such as when FIPS is in use)

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
Published Oct 19, 2019
Version 1.0

Was this article helpful?

8 Comments

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

  • 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! 👊

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