0-RTT resumption and packet encryption

A user revisits a site they visited yesterday. Their browser has a session ticket. QUIC sends the HTTP request in the very first packet — zero round trips — before the server even responds. But if an attacker intercepts and replays that first packet, the server will execute the request twice.

0-RTT resumption mechanics

On subsequent connections to the same server, the client can reuse a cached session ticket — a blob of encrypted TLS state the server issued at the end of the previous connection. The client includes this ticket in the ClientHello and attaches application data (0-RTT data) in the same Initial packet.

The server receives the Initial, decrypts the session ticket (which contains the resumption keys), and can immediately process the 0-RTT data — without waiting for a full handshake.

Latency: 0 RTT before the server processes the first request. On a 100 ms link, this is 100 ms saved on a reconnection — on top of the 100 ms already saved by the 1-RTT handshake vs. TCP+TLS.

The replay vulnerability

0-RTT data is encrypted with the session ticket’s symmetric key. An on-path attacker who captures the Initial packet can replay the entire packet to the server later. Because 0-RTT lacks TLS record-level replay protection, the server will receive and process the replayed request.

Concrete attack: Alice sends POST /api/transfer amount=5000 from=alice to=bob in 0-RTT. An attacker captures and replays the packet. The server executes the transfer twice: Alice loses 10,000 instead of 5,000.

The defense:

1. Restrict 0-RTT to idempotent requests only. GET, HEAD, and safe operations are safe — replaying them produces the same result. POST, DELETE, and state-changing operations must wait for 1-RTT keys.
2. 425 Too Early response. When the server forwards 0-RTT to an origin backend it includes an Early-Data: 1 header. The origin can respond 425 (Too Early) forcing the client to retry after the full handshake (RFC 8470).
3. Session ticket isolation. Servers should not share session ticket keys across data centers — a ticket from Server A should only be valid on Server A. Short ticket lifetimes (1–24 hours) limit the replay window.

Almost-full packet encryption

TCP headers are cleartext — source/dest IP, ports, sequence numbers are all visible to any observer. QUIC encrypts almost everything:

Long-form headers (handshake and Initial packets):

• Unencrypted: outermost 4 bytes (version + connection ID length) and the Connection ID itself.
• Encrypted: packet number, payload — using the appropriate level’s key.

Short-form headers (post-handshake packets):

• Carry only the connection ID and encrypted packet number + payload.
• Almost entirely opaque to observers.

Security consequences:

• An on-path attacker cannot inject RST packets — they cannot construct a valid encrypted packet without the 1-RTT key. TCP’s RST injection vulnerability is eliminated.
• Passive sniffing of stream contents is eliminated — all stream data is 1-RTT encrypted.
• Traffic analysis based on sequence numbers is impossible without decryption.

Operational consequence: tcpdump of QUIC traffic shows only opaque blobs. Network engineers cannot count HTTP requests per endpoint, identify slow clients, or detect misbehavior at the packet level without application-level instrumentation.