21 June 2021

I Can See Clearly Now…

By admin@labtinker.net

Wireshark is a powerful tool which captures no end of network protocols but 90% of the time you’re probably working with TCP and 90% of that TCP is probably http and 90% of that is probably encased in TLS encryption making it https. The problem here is that sometimes you need to see what’s inside those packets. The good news is you can using the method described here:

https://support.f5.com/csp/article/K50557518

Now, I’d variously heard this only worked with certain browsers and not at all with APIs and non-browser traffic so I decided to test it for myself.

To this end I am using a simple website I stood up in my lab on http://test.labtinker.net and also https://test.labtinker.net showing a picture of two Scandinoir enthusiasts before their trip to Copenhagnen:

There is a further element to be aware of which is the fact the decryption won’t work with key exchange protocols which give perfect secrecy, namely Diffie Helman. That is why in the latter section where the private key is imported into Wireshark – the option only mentions RSA keys. If you’re using Ephemeral Diffie Helman key exchange then you won’t be able to decrypt. You can tell what key exchange protocol you’re using by seeing what record is chosen in the TLS Server Hello, so RSA is good (for decryption purposes):

Whereas Diffie Helman Ephermal (DHE) isn’t:

…but really for security reasons you want DHE over RSA as perfect secrecy is very desirable because er… people can’t decrypt historic captures – like we’re trying to do here.

I neglected to check what cipher suite the various browsers in this lab had negotiated which would have been pertinent and useful to the post but this paragraph was added with the benefit of hindsight. Now on with the lab…

When we browse to above website using http, because nothing is encrypted we are able to see this image file from the packets we’ve caught in Wireshark using File/Export Objects/HTTP

The image file is called ‘boys.png’ and is visible for download:

So to test the decryption method descripted in the link above I’ll browse to the https version of the website and capture the output in Wireshark and see if the image is available. (Doing this without decryption there are no http objects that can be exported because they are all encrypted)

Essentially, the method in the link above involves defining a system variable which will capture pre-master secrets in a file and then pointing Wireshark at this.

When this is working you should see the file being filled up with Pre-Secrets

On Windows 10, this was one of those rare occasions when everything worked as expected and I could both see and export the image file from the Wireshark trace when browsing over https uisng Chrome, Mozilla and Edge (after making sure all caches were empty and the trace was restarted.). So far, so good… so what about a non-browser connection….

I used the Powershell Invoke-WebRequest command below:

I tried a ‘http’ request as a baseline and was able to see the ‘png’ file. However, when I tried with ‘https’ I was unable to see it which supports the theory that this method can only be used with browsers.

There is another method available: if you have the webserver’s private certificate (which I did) you can input it within Wireshark’s Protocol Preferences under ‘RSA keys list’

…you can add the RSA file. I specified the ip address the website was on, the port (443) and the protocol (http).

I tried this with a both a pfx and a pem file to no effect. There are apparently some limitations on this method, (TLS1.3 doesn’t work I seem to remember reading nor do certain ciphers) but I couldn’t find a great deal of information on this.

Linux

On Linux (Mint 21), I used Chrome and Firefox.

I firstly confirmed I could download the image file when using http.

As described in the method above I exported the SSLKEYLOGFILE whose location I pointed Wireshark at within TLS protocols and opened the browser from the same terminal window:

I also started Wireshark from this same terminal window…

this seemed to be necessary…. forgive the lack of clarity but with Linux I struggled to pin down consistent behaviour. Certainly, when I did the above with Chrome I saw the following in the http display within Wireshark…

So decryption was happening but within http objects I did not see the image file…

However, the text file confirmed decryption was happening (to some extent) as it contained the text below the picture…

…and to be honest you’re probably going to be more interested in text than pictures.

Firefox was less predictable and I although I was sure I had previoulsy had some success with https decryption I couldn’t reproduce it using the method described above when I re-tried

To try a non browser access method I used curl:

and the above method didn’t work for this nor did the the ‘private key’ method which had failed on Windows.