Using Wireshark to Troubleshoot network traffic encrypted by SSL/TLS

Have you ever gotten an error message complaining about secure negotiation? Most Sysadmins have. Where is that failure occurring? Do the client and server have a version of TLS in common which they both support? Is there at least one cipher they can agree on? By looking at the SSL/TLS handshake taking place, you can see exactly where communication is breaking down. The SSL/TLS handshake by necessity happens in the clear – you can’t send encrypted communication until that channel has been forged. What about messages sent later, encrypted over that secure tunnel? By providing Wireshark with the server’s private key, most of the time we can decrypt this traffic as well, right from within the Wireshark interface.

The exception to this, is if the cipher agreed upon between client and server leverages Diffie-Hellman. Perfect forward secrecy (PFS) thwarts Wireshark’s ability to decrypt the data after the fact, even with access to the server’s private key. As PFS is mandated by TLS 1.3, it’s time for those of us who are used to temporarily disabling DH ciphers to learn a new technique. Today, we will walk through the steps necessary to instruct Google Chrome to write a special logfile containing the DH Pre-Master key which will allow Wireshark to decrypt the conversation from the client’s perspective.

To start, navigate to the control panel. From the System tab, select Advanced System Settings. We will be creating an environment variable that will instruct Chrome to write out the logfile we need.

At the bottom, select Environment Variables.

Create a System Variable named SSLKeyLogFile with a path where you want the file to be written. Make sure all parent directories of this path exist!
Restart your machine for this configuration to take effect.

Download and install Wireshark (Which will install a library called Npcap) to your system. You will need to restart your machine again before you can use Wireshark.

When you open Wireshark, you will be met with this interface.

I have setup a test server on my local network with a self-signed certificate resolvable by my client at test.example.com. We will start a packet capture, navigate to this site, load the private key from the server, and view the now decrypted communications.

Next, we need to let Wireshark know we want to use this key in order to decrypt traffic to our server. Navigate to Edit -> Preferences -> Protocols and find TLS in the list.

Under Pre-Master Secret Log Filename, browse to the path we entered into the environment variable name. (The file will not be created until you’ve gone to an HTTPS site in your browser).

We will want to select whichever network interface is used to connect to the target server.

Select this interface and select Start.

You will see in real-time each connection your machine is making. Navigate in your browser to the site you’re looking to capture. Once the connection has been made, Wireshark will have recorded and decrypted it. Select the Stop button at the top.

Filter by the source IP of the server. For me, that’s 192.168.1.111 so my filter would look like this:

Wireshark has a rich feature language that’s worth becoming familiar with.

Notice that we have a tab now for “Decrypted TLS”. This is the plaintext payload we’re after!

Notice that this technique does not require the server’s private key, because we are decrypting the communication sent by the client from the client’s perspective in real time.

Make sure to delete the system environment variable and reboot your machine when your investigation is complete. Otherwise, a malicious application might be able to read that file and decrypt your traffic. From here, you can inspect the plaintext communication, or forward the decrypted traffic to your application vendor for support.