The TLS Handshake

The handshake is a negotiation followed by a proof. The client opens with a Client Hello: the highest TLS version it supports, a list of cipher suites in preference order, the hostname it wants (SNI, so a server hosting many sites can pick the right certificate), the application protocols it can speak (ALPN: h2, http/1.1, h3), and — in TLS 1.3 — a key share: a fresh ephemeral ECDHE public value, sent speculatively before it knows what the server will pick.

The server answers with a Server Hello choosing the version and suite, plus its own key share. At that moment both sides can compute the same shared secret, and in TLS 1.3 everything after the Server Hello is already encrypted with keys derived from it. The server then sends its Certificate chain, a CertificateVerify — a signature over the handshake transcript made with the certificate’s private key, which is what proves the server holds that key — and Finished, a MAC over the transcript that proves the negotiation was not tampered with.

The client validates the chain against its trust store (see Certificates and the Chain of Trust), checks the hostname, verifies the signature, verifies Finished, and sends its own Finished. From then on both sides exchange application data in encrypted records. Client authentication (mTLS) adds a CertificateRequest and a client certificate in the same flight; it is common between services, rare between browsers and websites.

Everything above is the TLS 1.3 flow; the exact messages depend on the version and the negotiated suite, and it is a mistake to describe "the" TLS handshake without saying which. In TLS 1.2 the client does not send a key share up front. It sends Client Hello, waits for Server Hello + Certificate + ServerKeyExchange (the server’s ECDHE value, signed) + ServerHelloDone, then sends ClientKeyExchange + ChangeCipherSpec + Finished, and only after the server’s ChangeCipherSpec + Finished can it send application data. That is two round trips before the first request byte, versus one for 1.3.

TLS 1.2 also allowed suites where the key exchange was RSA — the client encrypted a random premaster secret with the server’s public key. No ephemeral key means no forward secrecy: a stolen server key decrypts every recorded session. TLS 1.3 removed static RSA, removed every suite without AEAD (CBC-mode, RC4), removed renegotiation and compression, and cut the suite list to five names of the form TLS_AES_128_GCM_SHA256 — the key exchange and signature are negotiated separately via extensions rather than baked into the suite name.

Cipher suite strings therefore read differently by version. A 1.2 suite ECDHE-RSA-AES128-GCM-SHA256 names key exchange, authentication, cipher and hash; a 1.3 suite TLS_CHACHA20_POLY1305_SHA256 names only cipher and hash. When you see TLS_RSA_WITH_AES_256_CBC_SHA in a scan, that is a 1.2-era suite with no forward secrecy and a non-AEAD cipher — a finding, not a curiosity.

A full handshake costs an RTT and the asymmetric operations; a client returning to the same server should not pay again. After a 1.3 handshake the server sends one or more `NewSessionTicket` messages carrying an opaque, server-encrypted ticket. The client presents it as a pre-shared key in its next Client Hello and skips certificate transmission and verification; the handshake is still 1 RTT, and with psk_dhe_ke mode a fresh ECDHE exchange still happens so forward secrecy holds. TLS 1.2 had session IDs (server-side cache) and session tickets (RFC 5077) with an abbreviated 1-RTT handshake.

TLS 1.3 goes one step further: with a PSK the client may send 0-RTT early data — application bytes in the very first flight, encrypted under a key derived from the ticket, before any server response. The saving is an entire RTT for the first request. The cost is that early data is replayable: an attacker who captured the first flight can resend it and the server will decrypt and process it again, because nothing from the server has yet contributed freshness. 0-RTT is therefore safe only for requests that are idempotent by construction. Browsers and CDNs restrict it to GET without a body, and a well-configured server either rejects early data for non-idempotent paths or is engineered so that replaying them is harmless.

Tickets have a lifetime (hours to a week) and are bound to the server’s ticket-encryption key; rotating that key invalidates outstanding tickets, and a fleet behind a load balancer must share it or resumption silently fails and every connection pays a full handshake — visible as a jump in handshake CPU and latency after a deploy.

TLS runs over an established TCP connection, so its RTTs add to the The Three-Way Handshake. On a cold connection to a server 100 ms away: 1 RTT for SYN/SYN-ACK, then 1 RTT for TLS 1.3 (2 for 1.2), then 1 RTT for request and first byte of response — roughly 300 ms before any application data arrives with 1.3, 400 ms with 1.2, before a single byte of the page has been transferred. Cross-continent RTTs of 150–250 ms turn that into over half a second, which is the whole motivation for Keep-Alive and Connection Reuse and Connection Pooling (do the handshake once) and for QUIC (fold the transport and TLS handshakes into one RTT).

The CPU cost lands almost entirely in the handshake: a P-256 ECDHE plus an RSA-2048 signature verification is on the order of 100–300 µs on a modern core; an ECDSA P-256 server certificate makes the server’s signing side roughly ten times cheaper than RSA, which is why large deployments prefer ECDSA certificates. Once keys are established, AES-GCM with hardware support encrypts at several gigabytes per second per core — bulk encryption is rarely the bottleneck; handshake rate under a connection storm frequently is.