Analyze QUIC Traffic in Wireshark: Decrypt and Inspect (2026)

QUIC is designed to be resistant to eavesdropping, but that doesn’t mean you can’t inspect it if you have the right keys.

Let’s see QUIC in action, specifically how Wireshark can decrypt and analyze traffic that looks like gibberish by default.

Imagine you’re troubleshooting a web application that uses QUIC (which is becoming increasingly common for HTTP/3). You see slow load times or connection errors, and you want to see what’s happening at the packet level. Normally, QUIC traffic is encrypted end-to-end, making it unreadable in Wireshark.

Here’s a typical Wireshark capture of unencrypted QUIC traffic. Notice the QUIC protocol identifier, but the payload is opaque:

No.     Time      Source        Destination       Protocol Length Info
1       0.000000  192.168.1.100 104.26.3.117      QUIC     122    Initial, server_hello
2       0.034567  104.26.3.117  192.168.1.100     QUIC     250    Handshake, crypto, server_hello
3       0.045678  192.168.1.100 104.26.3.117      QUIC     300    Handshake, crypto, client_hello
4       0.078901  104.26.3.117  192.168.1.100     QUIC     500    Handshake, crypto, finished
5       0.089012  192.168.1.100 104.26.3.117      QUIC     600    1-RTT, application_data

The problem QUIC solves is the head-of-line blocking inherent in TCP, and it does this by multiplexing streams over a single UDP connection. It also aims to improve connection establishment speed and resilience to network changes. However, this comes at the cost of encryption being mandatory and tied into the connection handshake.

The key to decrypting QUIC traffic lies in obtaining the session’s TLS secrets. QUIC uses TLS 1.3 for its handshake, and Wireshark can use a "TLS session key log file" to decrypt these secrets. This log file records the cryptographic material exchanged during the TLS handshake.

The most common way to generate this log file is by setting an environment variable in the application or system performing the QUIC connection. For many applications, particularly browsers, this is SSLKEYLOGFILE.

Generating the TLS Session Key Log:

For Chrome/Chromium-based browsers: Open a terminal and launch Chrome with the SSLKEYLOGFILE environment variable set. Replace /path/to/sslkeys.log with your desired log file path.
- Linux/macOS:
```
SSLKEYLOGFILE=/path/to/sslkeys.log google-chrome --enable-quic
```
- Windows (Command Prompt):
```
set SSLKEYLOGFILE=C:\path\to\sslkeys.log
start chrome --enable-quic
```
- Windows (PowerShell):
```
$env:SSLKEYLOGFILE = "C:\path\to\sslkeys.log"
Start-Process chrome --enable-quic
```
For other applications: Consult their documentation. Some applications might have specific flags or configuration options to enable key logging. For example, curl can often be compiled with NSS_LOG or similar options.

Once you have your network capture (.pcapng file) and the sslkeys.log file, you can configure Wireshark.

Configuring Wireshark for Decryption:

Open Wireshark.
Go to Edit -> Preferences.
Navigate to Protocols -> TLS.
Under (Pre)-Master-Secret log filename, click Browse and select your sslkeys.log file.
Click OK.

Now, reopen your .pcapng file in Wireshark. If the traffic was captured while the SSLKEYLOGFILE environment variable was active and the log file was being written to, Wireshark should automatically decrypt the QUIC packets. You’ll see the QUIC protocol expand, and you’ll be able to inspect the application data, such as HTTP/3 frames.

The crucial detail often missed is that the SSLKEYLOGFILE needs to be active at the time the QUIC connection is established and the TLS handshake occurs. If you start logging after the handshake, Wireshark won’t be able to decrypt that specific session. The log file contains secrets that are unique to each TLS session.

The next logical step after decrypting QUIC traffic is to understand the specific HTTP/3 frames within it. Wireshark’s dissector for HTTP/3 works on top of the decrypted QUIC stream, allowing you to see individual GET, POST requests, HEADERS frames, DATA frames, and so on.