Wireshark TLS Decryption: Decrypt HTTPS with Session Keys (2026)

If you’re trying to decrypt TLS traffic in Wireshark and seeing gibberish instead of readable HTTPS, it’s because the session keys used to encrypt the traffic aren’t available to Wireshark by default.

The Problem: Encrypted Traffic

When a browser or client connects to a web server over HTTPS, they negotiate a unique, ephemeral session key. This key is used for that specific session only and is discarded afterward. Wireshark, by default, doesn’t have access to this ephemeral key, so it sees the encrypted data as meaningless bytes.

The Solution: Provide the Session Keys

The most common way to get Wireshark to decrypt this traffic is to have your browser or application log the TLS session keys to a file. This is often done using the SSLKEYLOGFILE environment variable.

Cause 1: SSLKEYLOGFILE Not Set (Most Common)

• Diagnosis: Check your environment variables.
  • On Linux/macOS: echo $SSLKEYLOGFILE
  • On Windows (Command Prompt): echo %SSLKEYLOGFILE%
  • On Windows (PowerShell): Get-ChildItem Env:SSLKEYLOGFILE If it’s not set, you’ll get no output or an empty string.
• Fix: Set the SSLKEYLOGFILE environment variable to a path where you want the keys logged.
  • Linux/macOS: export SSLKEYLOGFILE=/path/to/your/sslkeys.log
  • Windows (Command Prompt): set SSLKEYLOGFILE=C:\path\to\your\sslkeys.log
  • Windows (PowerShell): $env:SSLKEYLOGFILE = "C:\path\to\your\sslkeys.log" Important: You need to set this before starting the application or browser whose traffic you want to capture. For Firefox, you can set it in about:config by searching for security.ssl.keylog.file and entering the path. For Chrome/Chromium, you can launch it with a command-line flag: chrome --ssl-key-log-file=/path/to/your/sslkeys.log.
• Why it works: When this variable is set, many TLS libraries (like NSS, used by Firefox, and OpenSSL, used by many other applications) will automatically log the master secret and session keys for each handshake to the specified file. Wireshark can then read this file.

Cause 2: Incorrect File Format or Location

• Diagnosis: Open your sslkeys.log file. It should contain lines like: CLIENT_RANDOM <session_id> <master_key> or RSA SESSION-KEY: <session_id> <session_key> If the file is empty, has incorrect formatting, or is in a location Wireshark can’t access, decryption will fail.
• Fix: Ensure the path specified in SSLKEYLOGFILE is correct and writable by the application. Verify the file contains lines in the expected format. If it’s empty, the application might not be configured to log keys, or it might not be using a compatible TLS library.
• Why it works: Wireshark specifically looks for these formatted lines to find the necessary secrets to decrypt the traffic.

Cause 3: Wireshark Not Configured to Use the Key Log File

• Diagnosis: Even if the SSLKEYLOGFILE is set and populated, Wireshark needs to be told to use it. Go to Edit -> Preferences -> Protocols -> TLS. Check the "Pre-Master-Secret log filename" field.
• Fix: In the TLS preferences, click "Browse" and select the sslkeys.log file you created via the SSLKEYLOGFILE environment variable.
• Why it works: This tells Wireshark where to find the session keys it needs to decrypt the captured TLS packets.

Cause 4: Capturing Traffic Before Handshake Completes

• Diagnosis: If you start your Wireshark capture after the TLS handshake has already occurred, the session keys won’t be logged for that handshake. You’ll see the CLIENT_RANDOM or RSA SESSION-KEY entries for subsequent handshakes, but not the one corresponding to the traffic you’re interested in.
• Fix: Always start your Wireshark capture before initiating the TLS connection you want to decrypt. Ensure the application logs the keys during the handshake.
• Why it works: The session keys are generated during the TLS handshake. Wireshark needs access to these keys as they are generated to decrypt the subsequent encrypted application data.

Cause 5: Using HTTP/2 or HTTP/3 Over TLS

• Diagnosis: While the TLS handshake itself can be decrypted, the application-level multiplexing in HTTP/2 and HTTP/3 can sometimes complicate Wireshark’s ability to correctly reassemble and display the decrypted streams, especially if the key logging is inconsistent.
• Fix: Ensure your SSLKEYLOGFILE is correctly configured and populated. For HTTP/2, Wireshark generally handles it well once the TLS layer is decrypted. For HTTP/3 (which uses QUIC, not TCP), the decryption process is different and relies on QUIC-specific logging mechanisms, not the standard SSLKEYLOGFILE. You’d typically need to log the QUIC connection IDs and keys.
• Why it works: For HTTP/2, successful TLS decryption is the primary hurdle. For HTTP/3, the underlying QUIC protocol requires its own set of keys to be logged, which are managed differently.

Cause 6: Client-Side Certificate Authentication

• Diagnosis: If the server requires client-side certificate authentication, the TLS handshake is more complex. While the SSLKEYLOGFILE mechanism usually still works for decrypting the transport layer, the application behavior after authentication might be affected or lead to different traffic patterns.
• Fix: Ensure the SSLKEYLOGFILE is correctly set and that the client’s certificate is correctly configured in the browser/application. The decryption mechanism itself should remain the same.
• Why it works: The SSLKEYLOGFILE logs the master secret derived from the client random and server random, which is sufficient for decrypting the TLS session regardless of whether client authentication was part of the handshake.

Once you’ve correctly configured SSLKEYLOGFILE and pointed Wireshark to it, you should see the TLS layer turning from red (unencrypted) to black or grey (decrypted) for the relevant packets.

The next error you’ll likely encounter is Wireshark being unable to dissect the application protocol if the traffic isn’t standard HTTP (e.g., it’s a custom protocol, or a different version of HTTP than Wireshark expects).