← Back to Table of Contents

The 1-RTT Handshake

The biggest user-visible improvement in TLS 1.3: the handshake completes in one round trip instead of two.

The Trick

In TLS 1.2, the client waited to hear which key exchange the server picked before sending its key share. It’s like calling a restaurant and asking “what’s on the menu?” then waiting for the answer before placing your order. Two calls.

In TLS 1.3, the client guesses what the server will want and sends its order along with the first call. “Hi, I’d like a table, and I’ll probably have the pasta.” If the restaurant has pasta, great, one call. If not, they call back and say “we don’t have pasta, try again,” which adds a round trip, but that almost never happens.

In TLS 1.3, the client guesses which key exchange the server will pick and sends key shares for its best guesses upfront in the ClientHello. If the server supports one of them, the handshake completes in one round trip.

sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: ClientHello + key_share (X25519) + supported_versions (TLS 1.3)
    S->>S: Pick cipher suite and key share
    S->>S: Compute shared secret
    Note over S: Everything below is encrypted
    S->>C: ServerHello + key_share (server's X25519 public)
    S->>C: EncryptedExtensions
    S->>C: Certificate (encrypted!)
    S->>C: CertificateVerify (signature, encrypted!)
    S->>C: Finished

    C->>C: Compute shared secret
    C->>C: Decrypt and verify server messages
    C->>S: Finished

    Note over C,S: Application data can flow immediately
    C->>S: HTTP Request (encrypted)
    S->>C: HTTP Response (encrypted)

What Changed

ClientHello sends key shares upfront. The client includes one or more key_share entries (e.g., X25519 and P-256). The server picks one.

Server’s response is mostly encrypted. After the ServerHello (which contains the server’s key share), both sides can compute the shared secret. Everything after ServerHello is encrypted: the certificate, the CertificateVerify, and the Finished message. An eavesdropper can’t see the server’s certificate.

No ChangeCipherSpec. The switch to encryption happens implicitly after the key shares are exchanged.

HelloRetryRequest. If the server doesn’t support any of the client’s offered key shares, it sends a HelloRetryRequest asking the client to try again with different parameters. This adds a round trip but is rare in practice (most clients offer X25519, which most servers support).

The Performance Win

One round trip instead of two means the first byte of application data arrives sooner. On a fast network, this saves 50-100ms. On a slow or distant connection, it can save 200-500ms. For mobile users on cellular networks, this is significant.

Combined with 0-RTT (covered in the next few chapters), TLS 1.3 can achieve near-zero latency for repeat connections.

---

Next: The TLS 1.3 Key Schedule