Glossary Term
TLS Handshake
The TLS handshake negotiates keys and authenticates the server before HTTP data flows. See the TLS 1.3 round trip, ALPN, session resumption and 0-RTT risks.
TL;DR: The TLS handshake is the exchange before any HTTP bytes flow: agree on parameters, verify the server certificate, and derive shared keys. TLS 1.3 does it in one round trip.
The TLS handshake is the opening exchange in which a client and server negotiate a protocol version and cipher suite, authenticate the server with an X.509 certificate, and derive the symmetric keys that protect the rest of the connection. For HTTPS, it runs after the TCP handshake and before the first HTTP request.
What the messages carry (TLS 1.3)
- ClientHello: supported versions and ciphers, a key share, the server name (see SNI) and ALPN protocols such as
h2andhttp/1.1. - ServerHello and the rest of the server flight: chosen parameters and key share; everything after this is encrypted, including the certificate and a
Finishedmessage. - Client Finished: the client can now send HTTP in the same flight.
Abridged curl -v output (wording differs between curl and TLS library versions):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* ALPN: server accepted h2Non-obvious facts
- TCP plus TLS 1.3 is two round trips before the request. One for TCP, one for TLS. TLS 1.2 made it three. This is why connection reuse (keep-alive) matters so much for latency.
- Resumption skips most of the work. A returning client can present a session ticket and resume without a full key exchange.
- 0-RTT (early data) can be replayed. The server cannot tell a replayed early request from the original. RFC 8470 lets a server reply
425 Too Early; in practice only idempotent requests belong in early data. - ALPN decides HTTP version. If the server does not offer
h2, the connection falls back to HTTP/1.1; there is no separate upgrade step. - Handshake failures appear as TLS alerts, not HTTP statuses. There is no HTTP response yet, which is why browsers show
ERR_SSL_PROTOCOL_ERRORor a certificate error page rather than a status code. Behind Cloudflare, you may instead see a 525 when the CDN-to-origin handshake fails.
Go deeper
Frequently asked questions
What happens in a TLS handshake?
The client and server agree on a TLS version and cipher suite, exchange key shares, the server proves its identity with a certificate, and both derive symmetric keys. Then encrypted HTTP can begin.
How many round trips does a TLS 1.3 handshake take?
One, on top of the TCP handshake. TLS 1.2 needed two. HTTP/3 over QUIC combines the transport and TLS handshakes.
What is ALPN?
Application-Layer Protocol Negotiation is a TLS extension in which the client lists protocols such as h2 and http/1.1 and the server picks one, so HTTP/2 is selected without an extra round trip.
Is 0-RTT safe?
Not for requests with side effects. Early data can be replayed by an attacker, so servers should only accept idempotent requests in it and otherwise answer 425 Too Early.
Sources
Related
HTTPS Explained: How TLS Secures HTTP
HTTPS is HTTP over TLS. What the TLS handshake does, how certificates prove identity, what HTTPS hides and what it does not, and how to migrate a site safely.
425 Too Early: TLS 1.3 0-RTT Replay Protection
425 Too Early tells a client not to send a request in TLS early data because it could be replayed. See the Early-Data header and nginx config for 0-RTT.
Strict-Transport-Security (HSTS) Header: Setup and Preload
Strict-Transport-Security (HSTS) forces HTTPS for a set time. max-age, includeSubDomains, preload rules, nginx and Apache config, and how to roll it back.
NET::ERR_CERT_COMMON_NAME_INVALID: Fix the Name Mismatch
Fix NET::ERR_CERT_COMMON_NAME_INVALID and related ERR_CERT errors: SAN vs CN, wildcard limits, missing SNI, expired or incomplete chains, with openssl checks.