TLS handshake explained
A TLS handshake (often still called the SSL handshake) is how a browser and server agree on encryption before any HTTPS data flows: they pick a TLS version and cipher, the server proves who it is with its certificate, and both derive the same session keys. TLS 1.3 does it in one round trip, TLS 1.2 in two.
- ClientHello versions, ciphers, key share
- ServerHello key share, certificate, Finished
- Finished + request encrypted HTTP starts
Step through the messages
Press "Next message" or "Play" to start the handshake.
| Protocol | Round trips to first byte | At 100 ms RTT |
|---|---|---|
| TLS 1.2 | 4 | 400 ms |
| TLS 1.3 | 3 | 300 ms |
| TLS 1.3 0-RTT | 2 | 200 ms |
| HTTP/3 (QUIC) | 2 | 200 ms |
Excludes DNS lookup and server processing time. Each extra round trip also applies to every new third-party host a page connects to.
Why the handshake matters for speed
On a fibre connection near the server, a round trip might be 10 ms and the handshake is invisible. On mobile or across an ocean, 100–200 ms per round trip is normal, and a new TLS 1.2 connection costs 300–600 ms before the server even sees the request. That's the purple segment you see on the first request to each host in a waterfall chart.
The handshake is a nice example of a cost that is invisible in code but obvious once you watch it happen step by step. That step-by-step feeling is what ahaboo is built around, with guided explainers you work through by dragging and zooming to see how things click into place.
Why a TLS / SSL handshake fails
"SSL handshake failed" (or ERR_SSL_PROTOCOL_ERROR, SSL_ERROR_HANDSHAKE_FAILURE_ALERT, handshake_failure) means the two sides gave up before keys were agreed. The usual causes, roughly from most to least common:
- No shared protocol version or cipher. A server that only allows TLS 1.0/1.1, or an old client that only knows them. Modern browsers require TLS 1.2 or newer.
- Certificate problems. Expired, self-signed, issued for a different hostname, or missing its intermediate certificate, so the chain can't be verified.
- SNI mismatch. A server hosting many sites on one IP needs the hostname in the ClientHello; without it, it may return the wrong certificate or reset the connection.
- Something in the middle. Corporate proxies, antivirus "HTTPS scanning" or a wrong system clock (which makes valid certificates look expired).
The TLS checker tests the first three from outside: which TLS versions the server accepts, whether the certificate is valid for the hostname and trusted, and when it expires.
How to make the handshake cheaper
- Enable TLS 1.3 on your server or CDN — one round trip saved on every new connection.
- Turn on HTTP/3 where your CDN supports it; QUIC folds the transport handshake into TLS.
- Reuse connections: HTTP keep-alive and HTTP/2 let one handshake serve every request to that origin.
- Use fewer origins on the critical path, and
<link rel="preconnect">the ones you can't avoid so the handshake overlaps other work. - Keep certificate chains short and enable OCSP stapling so the browser doesn't have to fetch revocation data.
- Terminate TLS close to users with a CDN, which cuts the round-trip time itself.
See your own numbers: the TTFB test splits DNS, TCP and TLS for any HTTPS URL.
Questions developers ask
What is a TLS handshake?
The exchange at the start of every HTTPS connection in which the browser and server agree on a TLS version and cipher, the server proves its identity with a certificate, and both sides derive shared encryption keys. Only after it completes can the HTTP request be sent.
How many round trips does a TLS handshake take?
A full TLS 1.2 handshake takes two round trips; TLS 1.3 takes one. Both come after the TCP handshake (one more round trip), so a new HTTPS connection costs 2 round trips with TLS 1.3 and 3 with TLS 1.2 before the request goes out — plus DNS if the host is new.
What is TLS 1.3 0-RTT?
When a browser reconnects to a server it has talked to recently, TLS 1.3 can send the HTTP request together with the first handshake message using a pre-shared key, removing the TLS round trip entirely. Because such early data can be replayed, servers should only accept it for safe, idempotent requests like GET.
Is SSL handshake the same as TLS handshake?
People use both names, but SSL is the obsolete predecessor; all SSL versions and TLS 1.0/1.1 are deprecated. Modern browsers negotiate TLS 1.2 or 1.3. "SSL handshake" in tools and articles almost always means the TLS handshake.
How does HTTP/3 change the handshake?
HTTP/3 runs over QUIC, which combines the transport and TLS 1.3 handshakes into a single round trip — there is no separate TCP handshake. Resumed connections can use 0-RTT.
What does "SSL handshake failed" mean and how do I fix it?
The browser and server could not finish the handshake, so no encrypted connection exists and no page can load. Work through the usual causes in order: the server only accepts TLS versions or cipher suites the client does not (enable TLS 1.2 and 1.3); the certificate is expired, self-signed or issued for another hostname; the intermediate certificate is missing (serve the full chain); the server needs SNI and the client did not send it; or a proxy, antivirus or firewall is intercepting the connection. Our TLS checker tests the first three from outside in a few seconds.
What are the steps of a TLS handshake?
In TLS 1.3: (1) ClientHello with supported versions, cipher suites and a key share; (2) ServerHello with the server's key share, then the encrypted certificate, CertificateVerify and Finished; (3) the client checks the certificate and sends its own Finished, together with the first HTTP request. TLS 1.2 needs an extra exchange (ClientKeyExchange, ChangeCipherSpec) before the request can go out.
What is the difference between the TCP handshake and the TLS handshake?
The TCP handshake (SYN, SYN-ACK, ACK) opens a reliable connection between two machines; it knows nothing about encryption. The TLS handshake runs on top of that connection and sets up encryption and server identity. A new HTTPS connection needs both, one after the other, unless it uses HTTP/3, where QUIC merges them.
How do I see TLS time for my site?
In a waterfall it is the purple "SSL" or "TLS" segment of the first request to each host. Run the TLS checker on this site to see the handshake time, negotiated version and certificate for your domain, or the TTFB test to see DNS, connect and TLS next to server time.