How to decrypt TLS traffic in Wireshark

The reliable way to decrypt modern TLS traffic in Wireshark is to capture the connection and export its session secrets, usually in an SSLKEYLOGFILE. This works with TLS 1.2 and TLS 1.3 when the client, server, proxy, or controlled instrumentation can log the required secrets.

TLS provides several benefits, chief among them being the confidentiality and integrity of communications. When TLS is used, communications are encrypted, making it difficult for anyone to eavesdrop. Additionally, TLS can authenticate both sides of a communication, ensuring that data is not tampered with.

TLS data decryption in Wireshark is interesting for several reasons. It can help improve the accuracy of packet captures by allowing Wireshark to more accurately identify and decode TLS-encrypted traffic. Decryption can reveal otherwise hidden information, such as the contents of TLS-encrypted application data, and assist in troubleshooting potential issues with TLS configuration or implementation.

Different types of key exchanges

Older TLS connections that use RSA key exchange can sometimes be decrypted with the server private key in Wireshark's RSA keys list. This does not work merely because the server certificate uses an RSA key. It requires an RSA key-exchange cipher suite, the matching private key, a complete-enough handshake, and no ephemeral forward-secret key exchange.

Modern TLS commonly uses ephemeral (EC)DHE, and TLS 1.3 does not support static RSA key exchange. A server PEM file therefore cannot decrypt these sessions retroactively. Log the connection secrets while the controlled endpoint or intermediary establishes the session.

ECDHE Capture Setup

A typical capture setup might include a SPAN port on a managed switch, a TAP, a firewall, or capturing directly on the client or server. In the diagram, the capture device is different from the one where the SSLKEYLOGFILE is written. In simpler setups, both can reside on the same device: for example, capturing the browser's traffic on your local machine.

Note: If your primary interest is simply viewing HTTP data rather than analyzing complex TLS sessions, you might not need to perform full TLS decryption. Most modern browsers provide a Developer Tools Network tab that displays HTTP requests and responses in clear text. This can be a quick and convenient way to inspect the content without the additional setup required for TLS decryption in Wireshark.

ECDHE Decryption

To decrypt a modern TLS PCAP with Wireshark, you usually need an SSLKEYLOGFILE. Configure secret logging before establishing the connections. Session resumption creates additional secrets and may fail to decrypt when the key log begins too late or the capture misses required packets.

How to get the SSLKEYLOGFILE

Set the SSLKEYLOGFILE environment variable either globally or by starting your application from a terminal.

It is supported by Firefox, Chrome, Curl, mitmproxy, Exim, and others.

Windows

Windows CMD

C:\> set SSLKEYLOGFILE=%USERPROFILE%/Desktop/sslkeylog.log
C:\> echo %SSLKEYLOGFILE%

Windows PowerShell

PS C:\> $env:SSLKEYLOGFILE = "$env:USERPROFILE\sslkeylog.txt"
PS C:\> $env:SSLKEYLOGFILE

Chrome

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --ssl-key-log-file=%USERPROFILE%\Desktop\keylog.txt

Chrome with clean profile on macOS

SSLKEYLOGFILE=/tmp/tmp-google/.ssl-key.log /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=/tmp/tmp-google

Firefox

$env:SSLKEYLOGFILE = "%USERPROFILE%\Desktop\ffkeylog.txt";
'C:\Program Files\Mozilla Firefox\firefox.exe'

Linux / macOS

export SSLKEYLOGFILE=$HOME/sslkeylog.log
echo $SSLKEYLOGFILE

F5

Refer to K16700: Decrypting SSL traffic using the SSL::sessionsecret iRules command (11.6.x).

A typical key log file looks like this:

Below is a schema of the entire workflow for ECDHE:

Using Wireshark

To decrypt TLS data using Wireshark or editcap on both Windows and macOS, you'll need two files: the PCAP file and the SSLKEYLOGFILE.

For Wireshark:

1. Open Wireshark.
2. Go to "Preferences."
3. Navigate to "Protocols" -> "TLS."
4. In the TLS settings, find the option to set the (Pre)-Master-Secret log filename.
5. Enter the path to your SSLKEYLOGFILE.

This allows Wireshark to decrypt the TLS data using the provided key log file.

Using editcap

A useful trick is to use the editcap tool to inject the key log file into the PCAP file. With the PCAPNG format, you can merge the two files (PCAP and key log file) into a single file. When you open this new file, you can inspect the decrypted traffic in Wireshark without needing to configure any additional settings.

This is the command line for editcap:

editcap --inject-secrets tls,./keylog.txt ./tls.pcapng ./tls-encrypt-w-keys.pcapng

Be cautious not to share the PCAP with the keys with anyone who should not have access to the decrypted content.

What to do if data doesn't get decrypted

Check the evidence in this order:

• The key log and capture belong to the same process and connection attempt.
• The capture contains the handshake and enough packets in both directions.
• Allow subdissector to reassemble TCP streams is enabled.
• Out-of-order TCP reassembly is enabled when the trace needs it.
• The connection was not created before secret logging began or resumed with missing secrets.
• The traffic is actually TLS over TCP. QUIC uses TLS 1.3 secrets over UDP and requires suitable QUIC/TLS secret coverage.
• Wireshark is recent enough to decode the protocol and cipher suite in use.

RSA private-key decryption

For legacy static-RSA key exchange, the PCAP and matching PEM private key may be sufficient. This path does not decrypt ECDHE/DHE sessions or TLS 1.3 and should not be presented as the default modern workflow.

Active Man-in-the-Middle (MITM) Techniques and Alternative Key Capture Methods

In addition to passive key logging, active MITM attacks can be employed to extract keys from TLS traffic. In an active MITM scenario, you intercept and manipulate communications by creating a certificate for the server that is signed by your own Certificate Authority. Note:

• The client must have your Root CA in its trust store.
• Certificate pinning will fail, making this technique unsuitable for some applications.
• Mutual TLS and certificate pinning require explicit client/proxy compatibility and authorization; many interception setups will fail or alter the connection.

Several tools and devices support active MITM approaches:

• Next-Generation Firewalls: Devices like those from Palo Alto Networks (which can decrypt and re-encrypt traffic), Checkpoint, and Fortigate can be configured to intercept TLS communications.
• Application Delivery Controllers: F5 appliances can export TLS session keys using an iRule, and NetScaler can do the same during traffic capture.
• Proxy Applications: Tools such as Fiddler, Charles Proxy, BurpSuite, PolarProxy (which can save decrypted traffic in a PCAP), and mitmproxy (with the option to export TLS session keys) allow you to log and intercept keys during a TLS session.

Additional Key Capture Techniques

Beyond MITM approaches, consider these methods for capturing TLS keys:

• Memory Extraction:
  • On the host or virtual machine, extract keys directly from memory. This method is useful for forensic analysis and live monitoring.
  • Tools like TLSkex, TLSDump, DroidKex, TeleScope can extract keys from VM memory on the hypervisor.
• Proxy-Based Key Logging:
  • Configure a proxy (e.g., mitmproxy with the SSLKEYLOGFILE option) to log keys during TLS sessions.
• Traffic Reassembly Enhancements:
  • Enable reassembly at both the TCP and TLS layers, and also on the HTTP layer if the traffic is HTTPS.
  • Disable checksum validation on IP and TCP layers to avoid issues caused by checksum offloading, which can result in incorrect checksums and prevent proper reassembly.

Verifying successful decryption

Do not validate decryption from one label alone. Confirm that Wireshark exposes expected decrypted handshake and application-protocol fields, that stream reassembly is complete, and that the decoded requests or messages align with the known transaction.

Decryption answers “what application data is visible?” Root-cause analysis is the separate task of explaining which network event caused the failure. The network root-cause workflow shows why the decisive evidence can be the packet sequence around ClientHello and RST/ACK, not decrypted payload. PacketSafari's AI PCAP analyzer keeps that transport evidence, successful baselines, and remaining attribution questions together.