Every time a browser connects to an HTTPS site, it runs through a negotiation called the TLS handshake before a single byte of the actual page loads. It happens in well under a second, but it's doing real cryptographic work: agreeing on a protocol version, verifying identity, and establishing a shared secret that no eavesdropper on the network can derive — even one recording every packet.
The handshake, step by step (TLS 1.2)
1. ClientHello
The browser opens the connection by sending a ClientHello message: the highest TLS version it supports, a list of cipher suites it's willing to use, a randomly generated number, and (via the SNI extension) the exact hostname it's trying to reach — which is what lets one server present different certificates for different domains on the same IP address.
2. ServerHello and Certificate
The server responds by picking one TLS version and one cipher suite from the browser's offered list, generates its own random number, and sends its certificate (plus any intermediate certificates needed to build the chain of trust). The browser now has everything it needs to validate the certificate: checking the chain, expiry, hostname match, and revocation status.
3. Key exchange
This is the cryptographic core of the handshake. Using an algorithm like ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), both sides combine their own private, temporary values with public values exchanged over the connection to arrive at the same shared secret — without that secret ever being transmitted in a form an eavesdropper could extract. This is also what provides Perfect Forward Secrecy: because the key is temporary and derived fresh each session, a future leak of the server's long-term private key doesn't expose past sessions.
4. Finished, and encrypted traffic begins
Both sides send a "Finished" message, encrypted with the newly derived session key, confirming the handshake completed correctly and wasn't tampered with in transit. From this point forward, every byte exchanged — the HTML, images, form submissions, cookies — is encrypted using that session key with a fast symmetric cipher (like AES), which is far more efficient for bulk data than the asymmetric cryptography used during the handshake itself.
Why TLS 1.3 shortened this
TLS 1.3 collapses this into a single round trip by having the client guess the server's likely cipher suite preferences and send key exchange material in its very first message, rather than waiting for the server to state its preferences first. If the guess is right — which it usually is, since server configurations don't change often — the handshake completes in one round trip instead of two, meaningfully cutting the latency cost of every new HTTPS connection.
What can actually go wrong mid-handshake
A handshake can fail at several distinct points, and the failure mode usually tells you exactly where to look. A protocol version mismatch — a very old client that only speaks SSL 3.0 or TLS 1.0 hitting a server that's disabled those versions — fails immediately at the ClientHello stage, before any certificate is even exchanged. A cipher suite mismatch — no overlap between what the client offers and what the server allows — fails at the same early stage with a different, more specific error. A certificate problem (expired, wrong hostname, broken chain) fails later, after the server has sent its certificate, which is why certificate errors show a different browser message than a protocol-level failure.
This ordering is genuinely useful for debugging: if a connection fails before any certificate details are visible in a packet capture or browser network log, the problem is almost always a protocol or cipher suite mismatch at the server level, not anything wrong with the certificate itself.
The real-world cost of a round trip
A "round trip" isn't an abstract unit — it's bounded by actual network latency between client and server. On a fast connection with 20ms latency, a two-round-trip TLS 1.2 handshake adds roughly 40ms before any application data can even begin flowing; on a mobile connection with 150-200ms latency, that same handshake can add the better part of half a second, on top of DNS lookup and TCP connection setup that happen even before TLS starts. This is exactly why TLS 1.3's one-round-trip design, and session resumption for repeat visits, matter more in practice than they might seem to on paper — for a visitor on a slow or high-latency connection, cutting one round trip is often the single biggest handshake-related speed improvement available.
Handshake vs full connection setup
It's worth separating what TLS's handshake covers from the full cost of opening a new HTTPS connection: DNS resolution happens first, then a TCP three-way handshake establishes the underlying connection, and only then does the TLS handshake described above begin on top of it. HTTP/2 and connection reuse reduce how often this full sequence needs to repeat within a single page load — once a connection to a given host is open, subsequent requests to the same host can reuse it rather than paying handshake costs again, which is part of why the first request to a new domain is reliably the slowest one in any page load waterfall.
What happens when the handshake fails partway through
A handshake can fail at several distinct points, and the failure mode usually tells you where to look. A protocol version or cipher suite mismatch fails immediately at the ClientHello stage, before any certificate is even exchanged — this typically produces a generic connection error rather than a certificate warning. A certificate problem (expired, wrong hostname, broken chain) fails later, after the server has sent its certificate, producing the more familiar browser trust warning. This ordering is genuinely useful for debugging: if a connection fails before any certificate details are visible in a packet capture, the problem is almost always a protocol or cipher mismatch, not the certificate itself.
Session resumption: skipping most of this on a repeat visit
For a returning visitor within a short window, the browser and server can skip most of the full handshake entirely by reusing parameters from a previous session — either through a session ID the server remembers, or a session ticket the client presents. This is why loading a second page on the same site shortly after the first typically connects noticeably faster than the very first request did, and it's part of why real-world HTTPS performance is better than a naive count of "one full handshake per page load" would suggest.
Why the handshake's cost matters more on mobile connections
On a fast broadband connection with 20ms latency, a two-round-trip TLS 1.2 handshake adds roughly 40ms before any content loads — on a mobile connection with 150-200ms latency, that same handshake can add the better part of half a second, on top of DNS lookup and TCP setup that happen first. This is exactly why TLS 1.3's single-round-trip design and session resumption matter more in practice for mobile visitors than the numbers might suggest in isolation.
The handshake versus the full cost of a new connection
It's worth separating what the TLS handshake covers from the full cost of opening a new HTTPS connection entirely: DNS resolution happens first, then a TCP three-way handshake establishes the underlying connection, and only then does the TLS handshake described above begin. HTTP/2 and connection reuse reduce how often this full sequence needs to repeat within a single page load, which is part of why the very first request to a new domain is reliably the slowest one in any page load.
The handshake's design has been shaped directly by roughly a decade of named attacks against earlier versions — POODLE, FREAK, Logjam, and others each targeted a specific handshake weakness, and TLS 1.3's redesign closes off nearly every one of those paths by construction rather than through ongoing patching.
A quick closing checklist for verifying your own handshake is healthy
Confirm TLS 1.3 is enabled alongside 1.2, session resumption is functioning (check for a shorter handshake on repeat connections in DevTools), and no legacy protocol versions remain enabled — three checks covering the practical essentials of a modern, well-configured handshake.