How to Decrypt HTTPS Traffic in Wireshark | TLS 1.3 Packet Analysis

Introduction

When you capture HTTPS traffic in Wireshark, much of it appears as “Application Data,” and you cannot directly inspect the contents of HTTP requests and responses. This is because HTTPS traffic is encrypted with TLS.

With TLS 1.3 in particular, obtaining the server certificate’s private key alone is generally not enough to decrypt previously captured traffic.

This article explains how to use Google Chrome’s SSLKEYLOGFILE feature to obtain TLS keying material and decrypt TLS 1.3 HTTPS traffic in Wireshark using an actual packet capture.

Capturing HTTPS Traffic with Wireshark

Inspecting Encrypted Traffic

First, let’s see what TLS-encrypted HTTPS traffic looks like in Wireshark.

Launch Wireshark, start a packet capture, and access any website from your browser. In this example, the capture shows traffic generated when a website was accessed using Google Chrome on the local PC.

To display only traffic to and from a specific website, apply the following display filter:

ip.addr == XX.XX.XX.XX

In the capture results, much of the traffic is displayed as “Application Data.” Because it is encrypted with TLS, the contents of HTTP requests and responses cannot be inspected directly in this state.

How TLS 1.3 HTTPS Traffic Is Decrypted

Because the contents of HTTPS traffic are encrypted in TLS 1.3, capturing packets in Wireshark alone does not allow you to inspect HTTP requests or responses.

Furthermore, TLS 1.3 normally uses ephemeral key exchange based on (EC)DHE, so obtaining only the server certificate’s private key does not allow you to decrypt the traffic.

Instead, you can obtain TLS keying material—such as traffic secrets—from the client and load it into Wireshark to decrypt the encrypted HTTPS traffic.

Why the Server’s Private Key Alone Cannot Decrypt TLS 1.3

To decrypt TLS 1.3 HTTPS traffic in Wireshark, you need the keying material used to derive the encryption keys for the connection.

In TLS 1.3, a handshake with standard certificate authentication normally uses ephemeral key exchange based on (EC)DHE. The client and server generate a shared secret through the key exchange, then derive the Handshake Traffic Secret, Application Traffic Secret, and other secrets from it.

Because of this mechanism, even if the server certificate’s private key is compromised later, that private key alone cannot decrypt TLS traffic captured in the past. This property is known as forward secrecy.

Therefore, when analyzing TLS 1.3 traffic in Wireshark, an effective approach is to obtain traffic secrets and other keying material from the client’s TLS implementation.

Obtaining Keying Material with SSLKEYLOGFILE

Some applications, including Google Chrome, can write keying material that can be used to decrypt TLS traffic to a file when launched with the SSLKEYLOGFILE environment variable set.

First, launch PowerShell and set SSLKEYLOGFILE as shown below. Then launch Google Chrome from the same PowerShell session.

PS C:\Users\username> $env:SSLKEYLOGFILE = "$env:USERPROFILE\Desktop\sslkeys.log"
PS C:\Users\username> & "C:\Program Files\Google\Chrome\Application\chrome.exe"

Next, start a packet capture in Wireshark and access a website using the Google Chrome instance you launched. When TLS traffic occurs, sslkeys.log is created on the specified desktop.

If Chrome is already running, its existing process may be reused. If no keying material is written, exit Chrome completely and then launch it through PowerShell as described above.

When you inspect sslkeys.log, you will see keying material similar to the following. Wireshark uses these secrets to decrypt TLS traffic.

CLIENT_HANDSHAKE_TRAFFIC_SECRET <client_random> <secret>
SERVER_HANDSHAKE_TRAFFIC_SECRET <client_random> <secret>
CLIENT_TRAFFIC_SECRET_0 <client_random> <secret>
SERVER_TRAFFIC_SECRET_0 <client_random> <secret>
EXPORTER_SECRET <client_random> <secret>

The actual sslkeys.log file contains long hexadecimal values. Handle this file carefully: disclosing the keying material could allow someone to decrypt the corresponding traffic.

• CLIENT_HANDSHAKE_TRAFFIC_SECRET
  A secret used to derive the encryption key and related values for TLS handshake messages sent by the client.
• SERVER_HANDSHAKE_TRAFFIC_SECRET
  A secret used to derive the encryption key and related values for TLS handshake messages sent by the server.
• CLIENT_TRAFFIC_SECRET_0
  A secret used after the handshake to derive the traffic key, IV, and related values for application data sent by the client. It is used to decrypt data such as HTTP requests.
• SERVER_TRAFFIC_SECRET_0
  A secret used after the handshake to derive the traffic key, IV, and related values for application data sent by the server. It is used to decrypt data such as HTTP responses.
• EXPORTER_SECRET
  A secret used by TLS exporters to derive additional keying material for applications.

When a KeyUpdate occurs in TLS 1.3, the Application Traffic Secret is updated. In that case, the key log may contain secrets from later generations, such as CLIENT_TRAFFIC_SECRET_1 and SERVER_TRAFFIC_SECRET_1.

Note that a traffic secret is not passed directly to an encryption algorithm such as AES to encrypt traffic. TLS 1.3 derives a traffic key, IV, and related values from the traffic secret and uses the derived values for the actual encryption and decryption.

Configuring SSLKEYLOGFILE in Wireshark

Load the generated sslkeys.log file into Wireshark.

From the Wireshark menu, select “Edit” → “Preferences.”

Expand “Protocols.”

Select “TLS,” then specify the sslkeys.log file you created earlier in the “(Pre)-Master-Secret log filename” field. Click “Browse” to select the file.

Although the setting is named “(Pre)-Master-Secret,” for TLS 1.3 it can also load information recorded in SSLKEYLOGFILE, including Handshake Traffic Secrets and Application Traffic Secrets.

After selecting the file, click “Apply.”

Inspecting Decrypted HTTPS Traffic

The configuration is now complete. Finally, let’s verify that Wireshark can decrypt the traffic that was encrypted with TLS.

Before decryption, the packets were displayed as “Application Data,” and the contents of the HTTP traffic could not be inspected.

After loading sslkeys.log into Wireshark, however, you can inspect HTTP request content such as “GET /quiz/public HTTP/1.1.” This is possible because Wireshark decrypts the Application Data that was encrypted as TLS records and can then dissect the higher-layer protocols contained within it.

Troubleshooting Decryption Issues

• Did you exit Chrome completely before launching it?
  If an existing Chrome process is still running, the SSLKEYLOGFILE value set in PowerShell may not take effect.
• Does sslkeys.log contain keying material?
  Confirm not only that the file exists, but also that it contains entries such as CLIENT_TRAFFIC_SECRET_0.
• Did you specify the correct sslkeys.log file in Wireshark?
  In Wireshark’s TLS settings, confirm that you selected the key log file that Chrome is actually writing to.
• Does the keying material correspond to the captured traffic?
  You need the keying material for the TLS connection in the packet capture. Keying material obtained from a different session cannot decrypt it.

Conclusion

This article explained how to use Google Chrome’s SSLKEYLOGFILE feature to obtain keying material and decrypt TLS 1.3 HTTPS traffic in Wireshark.

The contents of TLS-encrypted Application Data cannot be inspected simply by capturing the traffic. In a test environment, however, if you can obtain the appropriate keying material from the client, Wireshark can provide detailed analysis of HTTP requests, responses, and other data.

This method is useful for troubleshooting HTTPS connection issues and investigating communication between applications. However, because a key log file contains sensitive information that can be used to decrypt TLS traffic, exercise great care when using this method in production environments and when storing or sharing the file.

References

TLS – Wireshark Wiki
Wireshark User’s Guide