Card 03/ 10

WalkthroughDifficulty: Intermediate2 min

The TLS 1.3 Handshake in One Round Trip

The client sends its key share in the first message, so encryption starts one round trip after TCP.

The TLS 1.3 handshake agrees on keys and proves the server's identity in a single round trip after the TCP handshake. The client guesses which key agreement method the server will accept and sends its half of the key in its first message, so the server can reply with its own half, its certificate and proof of identity all at once.

The TLS 1.3 handshake, with the point where encryption begins

The handshake, message by message

The client sends a ClientHello

It lists the TLS versions and ciphers it supports, names the site it wants in the server name field, and includes a key share: its half of a key exchange, on a method most servers accept.

The server sends a ServerHello

It picks a cipher and sends its own key share. From the two shares, each side computes the same secret, which nobody watching can compute. From here on, everything is encrypted.

The server proves its identity

It sends its certificate chain, then a CertificateVerify, a signature over the handshake made with the certificate's private key, which shows it holds that key. A Finished message closes its side.

The client checks and finishes

The client verifies the chain to a trusted root, checks the name and the signature, and sends its own Finished. It can send the HTTP request at once.

One round trip is the improvement over TLS 1.2, which needed two, because its client waited to learn the server's choices before sending a key share. On a 100 ms path, TLS 1.3 brings the first request forward by 100 ms on every new connection.

If the server does not support the method the client guessed, it asks for another share, costing one extra round trip; that is rare in practice.

A client returning to a server it has met recently can resume the session with a key it was given last time, skipping the certificate exchange. With 0-RTT, it can even send its request in the very first message, at the cost that an attacker could replay that request, so it is safe only for requests that can be repeated harmlessly.