Wireshark for TLS 1.3 and QUIC – Decrypting and Troubleshooting Morden Encrypted Traffic

—
Modern Internet traffic is heavily encrypted.
Websites, APIs, SaaS platforms, cloud services, collaboration platforms, CDNs, and mobile applications commonly use HTTPS.
Two technologies are especially important for modern packet analysis:
TLS 1.3
and
QUIC / HTTP/3
Traditional HTTPS commonly uses HTTP/1.1 or HTTP/2 over TLS and TCP.
HTTP/3 uses QUIC over UDP.
This changes how network engineers troubleshoot encrypted traffic.
With older TLS versions, more handshake information was visible in a passive packet capture.
TLS 1.3 encrypts more of the handshake.
QUIC goes further by replacing TCP with a secure transport protocol operating over UDP.
Wireshark can still provide extremely useful information, but the troubleshooting process needs to change.
In this article, we will learn:

• How TLS 1.3 differs from TLS 1.2

• How QUIC uses TLS 1.3

• How HTTP/3 works over QUIC

• What Wireshark can see without decryption

• How to capture TLS and QUIC traffic

• How to decrypt TLS 1.3

• How to decrypt QUIC and HTTP/3

• How to use SSLKEYLOGFILE

• How to troubleshoot blocked QUIC

• How to identify HTTP/3 fallback

• How to troubleshoot handshake failures

• How to analyze packet loss and timing

• How to build a repeatable Wireshark troubleshooting workflow

—

Understanding TLS 1.3 and QUIC

Before capturing packets, understand what is actually happening between the client and server.

TLS 1.2 at a High Level

A traditional TLS 1.2 handshake can include:

• ClientHello

• ServerHello

• Certificate

• Key exchange

• Cipher negotiation

• Finished messages

• Encrypted application data

More TLS 1.2 handshake information can be visible to a passive packet analyzer compared with TLS 1.3.

TLS 1.3 Handshake

TLS 1.3 simplified the handshake and removed many older cryptographic mechanisms.
A typical full TLS 1.3 handshake includes:

• ClientHello

• ServerHello

• EncryptedExtensions

• Certificate

• CertificateVerify

• Finished

• Application data

After ServerHello, much of the remaining TLS 1.3 handshake becomes cryptographically protected.
This includes the server certificate.

Why TLS 1.3 Is Faster

TLS 1.3 reduces the number of sequential negotiation steps required before secure application communication can begin.
A new TLS 1.3 connection can establish secure communication efficiently.
A resumed session can reduce connection-establishment latency further.

What Is QUIC?

QUIC is a secure transport protocol that operates over UDP.
It provides many functions traditionally associated with TCP, including:

• Reliable delivery

• Loss recovery

• Congestion control

• Flow control

• Connection management

• Multiple independent streams

QUIC integrates TLS 1.3 into its security architecture.
TLS handshake data is carried through QUIC CRYPTO frames.
QUIC then derives cryptographic secrets from TLS and uses them to protect QUIC packets.

QUIC Encryption Stages

QUIC communication uses different protection stages.
Important stages include:

• Initial

• 0-RTT

• Handshake

• 1-RTT

HTTP/2 vs HTTP/3

HTTP/2 normally uses:
TLS over TCP
HTTP/3 uses:
QUIC over UDP
A practical HTTP/3 deployment normally keeps both TCP 443 and UDP 443 available.

—

Build the SG Wireshark Lab

A controlled lab makes TLS and QUIC behavior much easier to understand.

Lab Components

Use:

• SG-Client

• Wireshark

• Router or NAT

• Optional firewall

• SG-Web server

• TCP 443

• UDP 443

Example Addressing

Use your actual server address when performing the lab.

Lab Objectives

We will perform four main exercises.

Test 1 — TLS 1.3 Without Decryption

Capture the TLS handshake and identify:

• TCP handshake

• ClientHello

• ServerHello

• Protected TLS handshake traffic

• Application Data

Test 2 — TLS 1.3 With Decryption

Use SSLKEYLOGFILE and inspect:

• HTTP/1.1

• HTTP/2

• HTTP headers

• Application requests and responses

Test 3 — QUIC Without Decryption

Capture UDP 443 and identify:

• QUIC Initial packets

• QUIC connection establishment

• Retry behavior

• UDP reachability

Test 4 — QUIC With Decryption

Use exported session secrets and inspect:

• QUIC streams

• HTTP/3

• HTTP headers

• HTTP requests

• HTTP responses

—

Capturing and Decrypting Traffic

Wireshark provides capture filters and display filters.
They serve different purposes.

Capture Filter for HTTPS

Use:

tcp port 443

Capture Filter for QUIC

Use:

udp port 443

Capture TCP and UDP 443

Use:

tcp port 443 or udp port 443

Capture Traffic for One Server

Example:

host 203.0.113.10 and (tcp port 443 or udp port 443)

Recommended Capture Workflow

TLS Display Filters

Show TLS:

tls

Show TLS handshakes:

tls.handshake

Show ClientHello:

tls.handshake.type == 1

Show ServerHello:

tls.handshake.type == 2

Show TLS alerts:

tls.alert_message

QUIC Display Filter

quic

HTTP/3 Display Filter

When HTTP/3 can be dissected:

http3

Show TCP and UDP 443

tcp.port == 443 || udp.port == 443

TLS 1.3 Decryption With SSLKEYLOGFILE

For modern TLS, session-key logging is one of the most useful Wireshark decryption methods.
Having only the HTTPS server private key is generally not sufficient for decrypting TLS 1.3 sessions.

Linux

Set:

export SSLKEYLOGFILE="$HOME/sslkeys.log"

Verify:

echo "$SSLKEYLOGFILE"

Example result:

/home/user/sslkeys.log

Launch a compatible browser or application from the environment where the variable is available.

Windows PowerShell

Set:

$env:SSLKEYLOGFILE="$env:USERPROFILEsslkeys.log"

Verify:

echo $env:SSLKEYLOGFILE

Then launch the compatible browser or application.

macOS

Use:

export SSLKEYLOGFILE="$HOME/sslkeys.log"

Verify the Key Log

Linux example:

ls -lh "$SSLKEYLOGFILE"

Inspect:

head "$SSLKEYLOGFILE"

Configure Wireshark

Open:
Edit → Preferences → Protocols → TLS
Locate:
(Pre)-Master-Secret log filename
Select:
sslkeys.log
Apply the setting.
Then start a fresh capture.

TLS Decryption Process

QUIC and HTTP/3 Decryption

QUIC also derives its protection secrets from TLS.
A compatible application can export secrets that Wireshark can use to decode protected QUIC communication.
The same key-log workflow can therefore help with HTTP/3 analysis when supported by the client and Wireshark.

—

Hands-On Wireshark Examples

These examples show how the protocols behave during real troubleshooting.

Example 1 — Analyze a TLS 1.3 Handshake

Start capturing:

tcp port 443

Open an HTTPS website.
Apply:

tls.handshake

Look for:

• ClientHello

• ServerHello

• Protected handshake traffic

• Application Data

Inspect ClientHello

Expand the ClientHello packet.
Useful information may include:

• Supported TLS versions

• Cipher suites

• Supported groups

• Key shares

• Extensions

• ALPN

• Server name information where visible

Example ALPN Negotiation

Example 2 — Decrypt HTTP/2

Configure SSLKEYLOGFILE.
Start Wireshark.
Generate a new HTTPS session.
Apply:

http2

If HTTP/2 was negotiated and the correct session secrets are available, Wireshark can expose HTTP/2 protocol details.

Example 3 — Capture QUIC

Start capturing:

udp port 443

Generate HTTP/3 traffic.
Apply:

quic

Look for QUIC connection-establishment traffic.

Example 4 — Force HTTP/3 With curl

First check curl capabilities:

curl -V

If HTTP/3 support is available:

curl --http3-only -I https://example.com/

This forces HTTP/3.
If HTTP/3 cannot be established, the test should fail instead of silently testing only HTTP/2.

Prefer HTTP/3 but Allow Fallback

Use:

curl --http3 -I https://example.com/

Example 5 — Demonstrate HTTP/3 Fallback

This is one of the most useful QUIC exercises.
Start with a test server that supports:

• HTTP/3 over UDP 443

• HTTP/2 over TCP 443

Verify HTTP/3:

curl --http3-only -I https://example.com/

In a controlled lab, block UDP 443.
Repeat:

curl --http3-only -I https://example.com/

Then test normal HTTPS:

curl -I https://example.com/

Example 6 — Repeated QUIC Initial Packets

Capture:

udp port 443

Apply:

quic

Suppose the client repeatedly sends QUIC connection-establishment packets and the connection never progresses.
Investigate:

• Whether the server replies

• UDP 443 firewall rules

• NAT

• Load balancer

• Server listener

• Packet loss

• Path MTU behavior

Example 7 — Compare Two Networks

Test the same HTTP/3 website using:

• Corporate network

• Mobile hotspot

—

Troubleshooting TLS 1.3 and QUIC

Troubleshoot modern encrypted traffic layer by layer.

TCP SYN Has No Response

For traditional HTTPS, inspect:

tcp.flags.syn == 1

If a client sends SYN packets and receives no SYN-ACK, investigate:

• Routing

• Firewall

• NAT

• Security group

• Load balancer

• Server TCP listener

This is a TCP connectivity problem before it is a TLS problem.

TCP Works but ServerHello Never Appears

First confirm:

• SYN

• SYN-ACK

• Final ACK

• ClientHello

If TCP successfully establishes and ClientHello is sent but the TLS exchange does not continue, investigate:

• Server TLS service

• Reverse proxy

• Load balancer

• TLS policy

• Server processing

• Routing asymmetry

• Middlebox behavior

TLS Alert Appears

Use:

tls.alert_message

Possible areas to investigate include:

• TLS version

• Certificate authentication

• Cipher configuration

• Key exchange

• ALPN

• Application policy

• Server configuration

Do not automatically interpret every handshake alert as a cipher mismatch.

Long Delay Before TLS Response

Measure timing rather than guessing.
Possible causes include:

• High network RTT

• Packet loss

• Server load

• TLS processing

• Proxy processing

• Load balancer processing

• Security inspection

QUIC Initial Repeats

Use the following troubleshooting path.

HTTP/2 Works but HTTP/3 Does Not

This is one of the most important QUIC troubleshooting scenarios.
HTTP/2 normally uses TCP 443.
HTTP/3 normally uses UDP 443.

Check:

• Client HTTP/3 support

• Local firewall

• Enterprise firewall

• ISP

• VPN

• Cloud firewall

• Security group

• Network ACL

• Load balancer

• NAT

• Server firewall

• HTTP/3 listener

HTTP/3 Falls Back to HTTP/2

Do not assume that fallback means:
Server does not support HTTP/3.
Possible causes include:

• UDP 443 blocked

• QUIC handshake failure

• Client behavior

• Browser policy

• Alt-Svc state

• Network delay

• Load balancer configuration

• Server configuration

Use:

curl --http3-only -I https://example.com/

to specifically test whether HTTP/3 can establish.

Large QUIC Transfers Fail but Small Requests Work

Investigate path MTU.
Possible symptoms include:

• Small requests work

• Larger transfers stall

• Problems occur only through VPN

• Problems occur on one ISP

• Intermittent QUIC behavior

Check:

• Interface MTU

• VPN overhead

• Tunnel overhead

• IPv4 vs IPv6

• ICMP behavior

• Firewall handling

• Load balancer behavior

• QUIC path MTU

Do not immediately reduce MTU randomly.
Identify the actual path limitation where possible.

Wireshark Cannot Decrypt TLS

Check:

• Was SSLKEYLOGFILE configured before opening the application?

• Did the application create the file?

• Does the file contain secrets?

• Is Wireshark using the correct file?

• Was the matching connection captured?

• Does the application support key logging?

Wireshark Cannot Decode HTTP/3

Check:

• Does the client actually support HTTP/3?

• Was UDP 443 captured?

• Did QUIC establish?

• Are matching session secrets available?

• Does the Wireshark version support the connection?

• Was HTTP/3 really negotiated?

Practical Troubleshooting Matrix

Complete Troubleshooting Workflow

—

Advanced Analysis and Best Practices

Modern encryption reduces passive visibility, but a packet capture can still provide important evidence.

ALPN

ALPN allows endpoints to negotiate the application protocol.
Examples include:
h2
http/1.1
h3
ALPN can help determine which HTTP protocol was selected.

SNI and ECH

Traditional TLS ClientHello traffic may expose the requested hostname through SNI.
However, Encrypted ClientHello can protect more ClientHello information.
Therefore, do not assume that SNI will always reveal the target hostname.

What Wireshark Can Show Without Decryption

Depending on the protocol, you may still analyze:

• Source IP

• Destination IP

• Ports

• Packet sizes

• Timing

• TCP handshake

• TCP resets

• TCP retransmissions

• QUIC Initial packets

• QUIC Retry

• UDP reachability

• Connection attempts

• Handshake progress

• Fallback behavior

What Decryption Adds

With valid matching session secrets, analysis can include:

• HTTP requests

• HTTP responses

• HTTP headers

• Status codes

• Redirects

• API calls

• Application errors

• HTTP/2

• HTTP/3

Capture From the Beginning

For the best troubleshooting results:

1. Close the existing connection.
2. Configure key logging if required.
3. Start Wireshark.
4. Start the capture.
5. Open the application.
6. Reproduce the issue.
7. Stop the capture.
8. Analyze the entire connection.

Capture at Multiple Points

For difficult network problems, capture from multiple locations when possible.
Examples include:

• Client

• Firewall ingress

• Firewall egress

• Load balancer

• Reverse proxy

• Server

Do Not Diagnose From One Packet

Avoid conclusions such as:

• TLS alert always means cipher mismatch

• Repeated QUIC Initial always means MTU

• HTTP/2 fallback always means no HTTP/3 support

• TCP retransmission always means server problem

• Missing ServerHello always means firewall

Analyze the packet sequence and surrounding evidence.

Protect Key Logs and Decrypted Captures

TLS key logs are sensitive.
A pcapng containing embedded decryption secrets can also expose application data.
Store and share these files carefully.

Delete Temporary Key Logs

Linux:

rm -f "$HOME/sslkeys.log"

Windows PowerShell:

Remove-Item "$env:USERPROFILEsslkeys.log"

Use a Current Wireshark Release

QUIC and HTTP/3 analysis continues to improve.
Use a currently supported Wireshark release rather than relying on an old minimum-version recommendation.
—

Quick Wireshark Reference

Capture HTTPS

tcp port 443

Capture QUIC

udp port 443

Capture Both

tcp port 443 or udp port 443

Show TLS

tls

Show TLS Handshake

tls.handshake

Show ClientHello

tls.handshake.type == 1

Show ServerHello

tls.handshake.type == 2

Show TLS Alerts

tls.alert_message

Show QUIC

quic

Show HTTP/3

http3

Show TCP or UDP 443

tcp.port == 443 || udp.port == 443

Force HTTP/3

curl --http3-only -I https://example.com/

Prefer HTTP/3 With Fallback

curl --http3 -I https://example.com/

Linux TLS Key Log

export SSLKEYLOGFILE="$HOME/sslkeys.log"

Windows TLS Key Log

$env:SSLKEYLOGFILE="$env:USERPROFILEsslkeys.log"

—

Summary

TLS 1.3 and QUIC have significantly changed modern packet analysis.
Traditional HTTPS commonly uses:
HTTP/2 over TLS and TCP
HTTP/3 uses:
HTTP/3 over QUIC and UDP
TLS 1.3 protects more handshake information than older TLS versions.
QUIC integrates TLS 1.3 into its connection establishment and packet-protection architecture.
This means that modern troubleshooting should separate the network layers carefully.
For traditional HTTPS:
Network → TCP → TLS → HTTP → Application
For HTTP/3:
Network → UDP → QUIC → HTTP/3 → Application
Wireshark remains extremely useful even without decryption.
It can help identify:

• Connectivity failures

• TCP handshake problems

• QUIC connection failures

• Timing problems

• Packet loss

• Retransmissions

• UDP blocking

• Protocol fallback

• TLS alerts

• Network-path problems

When authorized session secrets are available, Wireshark can provide much deeper visibility into HTTP/2 and HTTP/3 application traffic.

—

Useful Links and References

SanchitGurukul Static Resources

Related SanchitGurukul Articles

Official External References