Decrypting SSL traffic - PMS and egress

Forums Technical Forums
, , , ,
1

Hi - two questions combined.

Background - trying to catch and decipher tcpdump both for Client → VIP and F5-> Pool Members traffic

I’m following this tutorial: Decrypt with tcpdump --f5 ssl

I managed to catch the frontend traffic, but I’m struggling with creating the PMS key. I want to automate it using the provided wireshark cmd command, but I get the error:

C:\Program Files\Wireshark: invalid option -- ‘T’
C:\Program Files\Wireshark: invalid option -- ‘e’

I’m using Wireshark 3.4.8 - what would be the equivalent options for my version? Unfortunately using a Linux in this environment is out of the question. I can only work on Windows stepping stone and can’t send the captures to my PC

Second issue:

Catching the backend traffic does not produce the F5 TLS in the pcap capture… The server ssl profile is present, but I have no idea how to force the --f5 ssl option in tcpdump to catch the keys.

Will appreciate any advice - It is my second day struggling with the issue

2

Hello, I usually use an iRule to log and collect secrets which I’m attaching. This saves info in plain text in LTM file, eventually you can force log rotation and manually bulk-delete all lines from this iRule in “ltm.1” file when you’re done.

To retrieve info and create pms file, run this from bash shell.

sed -e 's/^.*\(RSA Session-ID\)/\1/;tx;d;:x' /var/log/ltm > /var/tmp/sessionsecrets.pms
grep -h -o 'CLIENT_RANDOM.*' /var/log/ltm >> /var/tmp/sessionsecrets.pms

To import PMS file in wireshark,

Edit → Preferences → Protocols → SSL => (Pre)-Master Secret log filename [Browse]

3

You must use tshark NOT wireshark to Automate Pre Master Secret File Creation.

This solution and the solution from CA_Valli does NOT work for TLS 1.3

To capture backend traffic also you must use the “-i 0.0:nnnp” option for tcpdump.

But it is possible to decrypt TLS 1.3 also, you must extract following fields from the dump:

  • CLIENT_EARLY_TRAFFIC_SECRET
  • CLIENT_HANDSHAKE_TRAFFIC_SECRET
  • SERVER_HANDSHAKE_TRAFFIC_SECRET
  • CLIENT_TRAFFIC_SECRET_0
  • SERVER_TRAFFIC_SECRET_0

In my tests tshark fails to dump this correctly. My old plan is to create a GitHub repo to upload my script that extracts all pre master secrets for all tls versions.

4

Please check this post:

Knowledge sharing: Troubleshooting/investigating SSL and HTTP issues

5

You can decrypt TLS1.3 with iRule method but you have to use the correct iRule as here: https://clouddocs.f5.com/training/community/adc/html/class4/module1/lab12.html#decrypt-ssl-with-irule.

6

You have to use the command line tshark.exe.  The other gotcha here is that with Wireshark running you have to have the F5 protocols enabled under Analyze, Enabled Protocols - search for F5 and make sure all the F5 protocols are enabled, otherwise the filters in that commandline will not work properly.  Once you enable the protocols in Wireshark GUI then the tshark.exe commandline has them enabled as well.

7

I have now uploaded my sycript to generate the pms file out of the tcpdump file with enabled sslprovider. This script works for all TLS versions and decrypts clientside and serverside traffic.

I use this script in my daily job and I hope it could help other people also!

8

@Bartek   - lots of answers here - did any of them get you where you needed to go? If yes, please make sure to mark it as an Accepted Solution so other users with your issue can quickly find help and the author gets credit. :slightly_smiling_face:

9

@Juergen_Mang

thank you for sharing your script.

Sorry to bump this old thread.

For some reason only the client side traffic get’s decrypted. Communication between LTM and nodes are still encrypted. I’m using the tcpdump command as mentioned in your github.

Any idea?

10

This is mostly the case, if:

  • tcpdump has not captured the initial tls handshake
  • HTTP/2 is used (the -p does not capture all http/2 streams)

Try to add the backend hosts to the filter and always reopen the browser.

11

One thing to take into account is if you have a OneConnect profile applied to the virtual server the Serverside connections could have established SSL handshakes before you take the capture and not be able to be decrypted.  You have to make sure all connections on the serverside and clientside are deleted before starting the capture otherwise you may not be able to decrypt.

You should also use a filter that includes the ServerSide nodes specifically and not rely on the :nnnp to gather that data if you are looking to decrypt the serverside traffic.

12

Hi,

thank you for your input.

Sadly it does not work.

  • did check if any tcp connection exists for this VS
  • used a fresh browser
  • no oneconnect profile
  • no http/2
  • added node IPs to tcpdump filter
  • one can see complete TCP and SSL handshake between LTM and node in the capture

The LTM still uses a rather old version (15.1), so maybe it’s an issue there?

13

That version should work.

  • Is there a ServerSSL profile?
  • Is there a HTTPS health monitor?
  • Is the pool member IP used in any other pools?

There are a number of ways there could be an open connection to the server that already establish the SSL handshake.  I’m wondering if it is something we are not thinking of that could have it open already.

14

Tried capturing a different VS (with same settings, profiles,..) on the same LTM. This time everything worked as expected.

So, never mind. Your scripts work. Thank you for sharing!

15

Glad that one is working.  If you would like to figure out where the open connection is I would do a quick tcpdump on the serverside of just that server and see if you can see an open connection and where it might be coming from.  I suspect once you get that connection to reset you will be able to capture from the original VS.