TLS and QUIC in a Capture

A capture of HTTPS traffic is often dismissed as unreadable. That is only half true. The payload is encrypted; the negotiation is not, and the negotiation is where most failures live.

TLS 1.2: the certificate is in the clear

ClientHello      SNI, supported versions, cipher suites, key share
ServerHello      chosen cipher, session ID
Certificate      the server's chain — readable
ServerKeyExchange / ServerHelloDone
ClientKeyExchange, ChangeCipherSpec, Finished

In 1.2 an observer sees the hostname (SNI), the certificate, and the negotiated cipher. That is enough to answer "which site," "is the certificate expired," and "did the server reject the protocol."

TLS 1.3: everything after the hello is encrypted

ClientHello      SNI, key share, supported versions
ServerHello      chosen key share
{EncryptedExtensions, Certificate, CertificateVerify, Finished}

The certificate is now inside the encrypted handshake. SNI is still plaintext unless Encrypted Client Hello is in use, which is rare in enterprise networks.

So in 1.3 you can still see which hostname was requested, and whether the server answered at all. You cannot see the certificate without keys.

QUIC: UDP 443

QUIC is TLS 1.3 inside UDP, with its own connection IDs and its own handshake. It exists because TCP head-of-line blocking hurts on lossy links, and because browsers wanted to own the transport.

What a capture shows:

• UDP 443 between client and server.
• An Initial packet with a QUIC header and, inside it, the TLS ClientHello — including SNI, unless ECH.
• Connection IDs that survive address changes, which is why a phone can move from Wi-Fi to cellular without dropping a video.

What it does not show: anything after the handshake, and nothing at all if the traffic is ECH-wrapped.

Filters worth knowing

tls.handshake.type == 1                    ClientHello
tls.handshake.extensions_server_name       SNI values
tls.alert_message                          handshake failures
quic                                       all QUIC
udp.port == 443                            QUIC by port
tcp.flags.reset == 1 && tcp.port == 443    resets on HTTPS

Reading a failure

ClientHello with no ServerHello. The server or something in front of it dropped the connection. Check policy, SNI-based blocking, and MTU.

ServerHello followed by an alert. The handshake failed after negotiation: protocol version, cipher mismatch, or certificate rejection. The alert code names the reason (40 handshake failure, 42 bad certificate, 70 protocol version).

Certificate visible and expired (1.2). The client will usually refuse. In 1.3 you will see the alert but not the certificate, so check the server directly.

Repeated ClientHello with different SNI. A client retrying after a block, or a proxy rewriting the name. Worth understanding before you assume the user typed the wrong URL.

Worked example: the site that loads for everyone but one VLAN

1. Capture at the gateway, filter tls.handshake.type == 1.
2. The ClientHello leaves with the correct SNI.
3. No ServerHello returns, but the TCP handshake completed.
4. A capture outside the firewall shows the ServerHello arriving at the edge and not leaving.
5. The egress policy is blocking by SNI category, and this VLAN's policy differs from the others.

The capture did not decrypt anything. It located the drop, which is the point.

What breaks in production

• Assuming you can see URLs. You cannot, even with TLS 1.2.
• Forgetting QUIC. A capture filtered to TCP misses a growing share of web traffic.
• Expecting certificates in 1.3. They are encrypted; use openssl s_client against the host.
• Decrypting without a lawful basis. SSL key logging requires access to the client or server; in a district, that is a policy decision, not a troubleshooting shortcut.
• ECH. When it is deployed, even the hostname disappears; treat it as opaque and rely on endpoint telemetry.

Checklist

1. You know which TLS version the failing flow negotiated.
2. SNI is checked before assuming the destination.
3. UDP 443 is either captured or explicitly blocked.
4. Alerts are read as codes, not as "TLS error."
5. Decryption is a documented policy decision, never an ad-hoc step.

Next

Individual patterns are useful. Continue with Five Patterns That Explain Most Tickets, which combines them into a triage method.