How the TLS Handshake Works

The TLS handshake is the sequence of messages a client and server exchange to agree on encryption parameters, verify the server’s identity, and establish shared secret keys — all before a single byte of actual application data gets sent. It’s what happens in the fraction of a second between your browser requesting an HTTPS page and the connection being ready to carry encrypted traffic.

Why a handshake is needed at all

Symmetric encryption — the kind used to actually encrypt the bulk of a TLS connection’s traffic — needs both sides to share the same secret key, but you can’t just send that key over the open internet without an eavesdropper capturing it too. The handshake solves this using asymmetric cryptography (a public/private key pair) to establish a shared secret securely, then switches to fast symmetric encryption for the actual session. It also verifies that the server is who it claims to be, using a certificate signed by a trusted authority, so the client isn’t handing data to an impostor.

The TLS 1.3 handshake, step by step

Modern TLS (version 1.3) trimmed the handshake to a single round trip, down from two in TLS 1.2:

1. Client hello. The client sends the TLS versions and cipher suites it supports, plus a randomly generated value and its preferred key-exchange parameters, guessing which one the server will pick.
2. Server hello, certificate, and key exchange. The server picks a cipher suite, sends back its own random value and key-exchange parameters, and sends its certificate — a document, signed by a certificate authority, binding the server’s public key to its domain name.
3. Certificate verification. The client checks the certificate: is it signed by a certificate authority the client trusts, is it still within its validity window, and does the domain name match the one being requested. If any check fails, the browser shows a warning and refuses to proceed silently.
4. Key derivation. Both sides independently combine the exchanged key material (typically via Diffie-Hellman key exchange) to compute the same symmetric session keys — without ever transmitting the key itself over the wire. This is the core trick that makes the handshake secure even though it happens in plaintext-visible message exchanges.
5. Finished messages. Both sides send a message encrypted with the newly derived keys, confirming the handshake completed correctly and that no tampering occurred in transit.

After that, every subsequent message on the connection is encrypted with the derived symmetric keys, and the actual HTTP request finally goes out.

What the certificate actually proves

The certificate doesn’t prove the server is trustworthy or secure — only that a certificate authority verified, at issuance time, that whoever requested the certificate controlled the domain it names. That’s a narrower guarantee than it sounds: it stops an attacker from impersonating yourbank.com without also controlling that domain, but it says nothing about what the server does with your data once the encrypted connection is established. Certificate validation is also the layer that DNSSEC complements rather than replaces — DNSSEC protects the lookup that resolves a domain to an IP address; TLS protects and authenticates the connection to whatever’s actually listening at that address.

Session resumption

Running the full handshake on every connection would be wasteful for a site the client visits repeatedly, so TLS supports resuming a previous session using a cached key rather than renegotiating from scratch. TLS 1.3 goes further with “0-RTT” resumption, letting a returning client send encrypted application data in its very first message — at the cost of some replay-attack considerations that make it unsuitable for non-idempotent requests, which is a reasonable trade for things like re-fetching a cached static asset but not for something like submitting a payment.

TLS 1.2 vs TLS 1.3

	TLS 1.2	TLS 1.3
Round trips to complete handshake	2	1
Supports 0-RTT resumption	No	Yes
Weak/legacy cipher suites allowed	Yes	Removed
Handshake messages encrypted	Only after the exchange	Encrypted earlier in the flow

Where the handshake fits in a request’s lifecycle

The TLS handshake happens after the DNS lookup resolves a domain to an IP address and the TCP connection is established, and before any HTTP request is sent — it’s pure overhead in terms of round trips, which is exactly why techniques like preconnect exist: doing the DNS lookup, TCP handshake, and TLS handshake ahead of time for an origin you know you’ll need means the actual request, when it finally goes out, doesn’t have to wait for any of it.

The takeaway

The TLS handshake lets a client and server agree on encryption keys without ever transmitting the key itself, and lets the client verify the server’s identity via a signed certificate, all in a single round trip under TLS 1.3. Everything after the handshake — the actual HTTP request and response — travels encrypted with the keys it established. It’s overhead you pay once per connection, which is exactly why connection reuse and resumption exist to avoid paying it more than necessary.