Hello Internet, I am Matt and this is Forensics with Matt. In today’s post, I will share the process I used to gain access to the information that is contained within the packets found generated by secure network protocols including HTTPS, TCP, TLSv1.2, TLSv1.3 and other secure protocols. This is a very interesting trick that’s useful in some situations that will be discussed later on.
Before we get into this, let’s talk about my most recent video. In the most recent video, I talked about the capture filters in Wireshark. I didn’t include the display filters, as my last post contained, because the video was getting a bit too long and I wanted to practice them better. In the coming week or two, I will make a video that does the rest of the filters I need. Here’s the video.
Now without further adieu, let’s get into the video.
Why decrypt packets in Wireshark?
Why would we even bother decrypting traffic? These days, most of the internet is wrapped in HTTPS. That’s good for privacy, but it also means that if you’re troubleshooting, testing, or investigating something, all you see in Wireshark is a blur of encrypted gibberish. By decrypting, you can see what your apps and browsers are actually sending and receiving. It’s useful for debugging APIs, performing security audits, or just learning how TLS really works. If encrypted traffic is a vault, having the right setup in Wireshark is like holding the key.
Get the secrets in Windows.
On Windows, the process is pretty straightforward. You set an environment variable so your browser writes out the cryptographic keys it uses. In System Properties → Advanced → Environment Variables, add a new user variable called SSLKEYLOGFILE and point it to a file like C:\sslkeylog.txt. Then, when you start Firefox or Chrome, they’ll quietly record pre-master secrets in that file. In Wireshark, go to Edit → Preferences → Protocols → TLS and point the “(Pre)-Master-Secret log filename” option to that same file. Once you start capturing, you’ll see decrypted HTTPS traffic right there in your packet list.
And secrets in Mac…
On macOS, the idea is the same, just with a Unix flavor. You define the SSLKEYLOGFILE variable in your shell profile, for example adding export SSLKEYLOGFILE=~/sslkeylog.txt to your ~/.zshrc. Then launch your browser from the terminal so it writes the secrets to that file. The file will come out looking something like what you see in Figure 1:
Figure 1: SSLKEYLOG file
In Wireshark, go to the TLS settings as before and point it to the key log. From then on, captured TLS traffic opens up and you’ll see the plaintext HTTP under the encryption. The figure below shows the before and after of adding in the SSLKEYLOG file.
Figure 2: Comparison between encrypted and decrypted information.
An interesting addition…
There are a couple of extra tricks worth knowing. With the editcap tool, you can actually merge the key log into a capture file so it carries its own decryption material. The command looks like editcap --inject-secrets tls,keylog.txt in.pcapng out-with-keys.pcapng. That way, anyone opening the new capture in Wireshark can see the decrypted streams without extra configuration. And while browsers make this process easy, non-browser apps are trickier. In some cases you’d need the server’s private key or special debugging hooks, especially with TLS 1.3, which makes forward secrecy the norm.
Conclusion
In conclusion, decrypting traffic in Wireshark changes the game from staring at unreadable ciphertext to actually seeing what’s happening inside the session. It’s not something you’ll use every day, but when you need to troubleshoot or audit, it’s like flipping the light switch in a dark room. The tools are there—you just need to point Wireshark in the right direction and let the secrets spill.
Special thanks for the producers at Hackersploit for publishing a video that I grabbed my interesting information in the figures for. Also, Id like to say that the video for this post will go in a similar direction to their post, given that the time I have to make it is short at this point.
Until next time, if you like, say so and if you love this post share it and tell me what you think. This has been Matt from Forensics with Matt, talking about decrypting Wireshark Traffic. Until next time, Matt Out!