Session resumption and 0-RTT

The first TLS connection to a server costs one full RTT. But when you reload the same page five minutes later, the browser already knows that server. TLS 1.3 lets it skip certificate validation entirely and — in the right conditions — attach the first request to the handshake itself, paying zero extra RTTs.

NewSessionTicket and PSK resumption

After a successful handshake, the server sends a NewSessionTicket message — an encrypted blob containing a pre-shared key (PSK) and metadata (ticket age, lifetime). The client caches it keyed by hostname.

On the next connection to the same server, the client includes a pre_shared_key extension in its ClientHello with the ticket. The server decrypts the ticket, recognizes the PSK, and skips certificate validation entirely. It derives the session keys from the PSK instead of ECDHE.

Cost: still one full RTT (the ClientHello must still reach the server), but no expensive PKI operations. Certificate parsing and chain validation are eliminated.

0-RTT early data

If the browser has a cached PSK, it can encrypt the first request using the PSK’s key and attach it to the ClientHello itself — before the handshake completes. The server decrypts and processes the request immediately, then sends both the handshake response and the application response. Cost for the request: zero extra RTTs.

The replay problem

0-RTT has a fundamental security weakness: it is not protected against replay attacks. An attacker on the wire can capture the 0-RTT ClientHello and resend it to the server. The server, seeing a valid PSK ticket and valid early data, may process the request again.

• For GET /news: replay is harmless — same read, same result.
• For POST /transfer: replay is catastrophic — the database row is created twice, money is transferred twice.

The simplest rule: 0-RTT is only safe for idempotent requests where replaying produces no additional side effects. GET, HEAD, and OPTIONS are typically safe. POST, PUT, DELETE that mutate state are unsafe.

RFC 8470 and 425 Too Early

RFC 8470 defines the HTTP response code 425 Too Early: the server returns this status when it receives a 0-RTT request for a route that is not safe to replay. The client must retry after the handshake completes. Frameworks (Spring, Express, Caddy) expose middleware that inspects the Early-Data: 1 request header and returns 425 Too Early for any handler that mutates state.