How to decrypt TLS traffic in Wireshark
Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. TLS uses a combination of public-key and symmetric-key cryptography, making it ideal for securing communications over the Internet. Wireshark is a free and open-source packet analyzer. It is used for network troubleshooting, analysis, software and communications protocol development, and education.
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
The most common type of encryption used with TLS used to be RSA, which can be decrypted using Wireshark's RSA keys list. To decrypt these exchanges, you need to use Wireshark's TLS decryption feature and have the server's private key (a *.pem
file).
Nowadays, ephemeral Diffie-Hellman is more prevalent. You can decrypt this kind of traffic as well. However, the drawback is that you must record the used keys while capturing with Wireshark. The decryption keys are temporary, meaning they change for every connection. This is why you cannot simply export a PEM file from a server to decrypt the TLS traffic; you need to capture the ephemeral keys as they are used by the browser, server, or TLS inspection device.
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 PCAP with Wireshark, you need to have an SSLKEYLOGFILE
. This file can be created in various ways depending on the device you control. You must configure your system to log encryption keys to an SSLKEYLOGFILE before you start capturing network traffic, or you won't be able to decrypt the captured traffic.
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:
- Open Wireshark.
- Go to "Preferences."
- Navigate to "Protocols" -> "TLS."
- In the TLS settings, find the option to set the (Pre)-Master-Secret log filename.
- 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
The following TCP protocol preferences are also required to enable TLS decryption:
- Allow subdissector to reassemble TCP streams: Enabled by default.
- Reassemble out-of-order segments: Since Wireshark 3.0, this is disabled by default.
RSA Decryption
To decrypt RSA-encrypted traffic, you only need the PCAP and a PEM file.
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 cannot be supported, as it requires the client to verify its own certificate.
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:
- Proxy-Based Key Logging:
- Configure a proxy (e.g., mitmproxy with the
SSLKEYLOGFILE
option) to log keys during TLS sessions.
- Configure a proxy (e.g., mitmproxy with the
- 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
The best way to confirm that decryption was successful is to filter on the TLS handshake in Wireshark. If the "Encrypted Handshake Message" is replaced by "Finished," the decryption process has been successful.