What is a TLS handshake, and how does it work?

What happens during a TLS handshake, step by step?

Here is one real handshake, using TLS 1.3 (RFC 8446), the version most browsers negotiate by default in 2026:

• ClientHello. The client sends a random value, the TLS versions and cipher suites it supports, and a key_share: its own half of a Diffie-Hellman key exchange for a group it is willing to use (commonly X25519 or P-256). Offering key material in the very first message, instead of waiting to be asked, is the biggest structural change from TLS 1.2.
• ServerHello. The server picks a version and cipher suite and replies with its own key_share for the same group. Both sides now have enough to compute the same shared secret independently, without either one sending that secret across the network. RFC 8446 Section 2 calls this the "Key Exchange" phase.
• Certificate and CertificateVerify. Every message from here on is encrypted under keys derived from that shared secret. The server sends EncryptedExtensions, then its Certificate chain and a CertificateVerify message, defined in RFC 8446 Section 4.4.3 as "a signature over the entire handshake using the private key corresponding to the public key in the Certificate message." That signature proves the server holds the private key for the certificate it just presented.
• Finished. Both the server and, after it, the client send a Finished message: a MAC over the full handshake transcript so far. If an attacker had altered any earlier message, the transcripts on each side would no longer match and the check would fail. Once the client's Finished message goes out, the actual page request can start flowing.

The whole exchange above takes one round trip: the client's first flight and the server's reply are enough to authenticate the server and start encrypted traffic. RFC 8446 documents this as the standard "1-RTT" handshake.

What did TLS 1.3 change from TLS 1.2?

TLS 1.2 (RFC 5246) needs two round trips for a full handshake: ClientHello, then a server flight of ServerHello, Certificate, an optional ServerKeyExchange and ServerHelloDone, then a second client flight carrying ClientKeyExchange and the client's Finished before the server's own Finished can go out. TLS 1.3 folds the key exchange into the first pair of messages instead, which is what gets it down to one round trip.

RFC 8446 Section 1.2 also lists what got removed outright, not just reordered:

• Static RSA and static Diffie-Hellman key exchange. Every cipher suite now uses an ephemeral key exchange, so a stolen server private key cannot decrypt previously captured traffic.
• Compression and renegotiation. Both had known attacks; RFC 8446 states plainly that "TLS 1.3 forbids renegotiation."
• Custom, unauthenticated Diffie-Hellman groups. Only a small, named set of well-vetted groups is allowed now.
• MD5 and SHA-1 in signatures, plus RC4, DES, 3DES and export-grade ciphers. Every remaining cipher suite is an AEAD construction (AES-GCM or ChaCha20-Poly1305), authenticating data as it encrypts it instead of needing a separate integrity check.

The practical effect is a shorter list of things a server can misconfigure. A TLS 1.3-only server cannot accidentally offer a weak cipher suite, because none exist to offer.

What is session resumption, and what is 0-RTT?

Running the full handshake for every connection would be wasteful when the same two parties already talked recently. TLS 1.2 solved this with a session ID or a session ticket, letting the client skip straight to Finished messages next time, which cuts a full handshake down to one round trip. TLS 1.3 replaces both with pre-shared keys (PSK): after a handshake finishes, the server sends a NewSessionTicket carrying a key derived from that session, and the client presents it next time instead of negotiating from scratch.

0-RTT goes further. RFC 8446 describes it as a mode "added, saving a round trip at connection setup for some application data": with a valid PSK, the client can send its first request alongside its very first flight, before hearing back from the server at all. The tradeoff is real: RFC 8446 states plainly that 0-RTT data "is not forward secret" and carries no guarantee against replay, so it only belongs on requests safe to receive twice, never on anything that changes state, like a payment.

What is SNI, and why does shared hosting depend on it?

Server Name Indication is a ClientHello extension, defined in RFC 6066, that exists because of a chicken-and-egg problem: a server needs to know which certificate to present before it can encrypt anything, but the hostname the client wants was traditionally visible only inside the encrypted HTTP request that comes later. RFC 6066 Section 3 frames the gap directly: "TLS does not provide a mechanism for a client to tell a server the name of the server it is contacting," and adds that this matters "to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address."

SNI closes that gap by having the client send the hostname, in plain text, as part of the ClientHello itself. A shared host or a CDN edge holding hundreds of certificates on one IP address reads that field and picks the matching certificate before the handshake continues. Without SNI, a server fronting multiple domains on one IP has no reliable way to know which certificate to hand back, and older clients or misconfigured servers that skip it are the classic cause of a handshake that fails on one hostname sharing an IP with others.

What is ALPN for?

Application-Layer Protocol Negotiation, defined in RFC 7301, is a separate extension riding along in the same ClientHello and the server's EncryptedExtensions. It lets the client list the application protocols it can speak, most commonly HTTP/2 ("h2") and HTTP/1.1, and the server picks one during the handshake itself. Before ALPN existed, that negotiation happened after the handshake finished, as a separate exchange that cost time on every connection. Folding it into the handshake is a small change with an outsized effect: it is why a browser and a modern web server agree to speak HTTP/2 without an extra round trip to ask.

All of this happens between a click and a page starting to render, and any single step can fail silently: a certificate can expire, an intermediate can go missing, a server can drop a cipher suite a client still needs. Running a real handshake against a live host, the way the SSL/TLS check tool does, is the direct way to see which step breaks rather than guessing from a browser error page. HostTracker has monitored websites since 2004, checks from 300+ checkpoints in 158 cities, and can alert by email, SMS, voice call, Slack, Telegram and more the moment an SSL monitor sees a handshake that fails.

Frequently asked questions

Is SSL the same thing as TLS?

No, though the names get used interchangeably. SSL is the older protocol family; TLS 1.0 was its direct successor, and every version since has been TLS, up through TLS 1.3 today. "SSL handshake" and "SSL certificate" survived as everyday terms even though the SSL protocol itself retired years ago.

Why does the handshake need a certificate at all?

Encryption alone only stops a passive eavesdropper from reading the traffic. Without a certificate proving who the server is, nothing stops an attacker from sitting in the middle and running the same encrypted handshake with both sides separately. The certificate, and the CertificateVerify signature proving the server holds its matching private key, is what turns encryption into encryption with a known party.

What is the difference between the TLS handshake and mutual TLS?

The handshake described here authenticates only the server; the client stays anonymous at the TLS layer and usually proves who it is afterward, inside the encrypted connection, with a password or a token. Mutual TLS adds a second certificate check in the other direction, so the server also verifies the client's identity before the handshake completes. See what mutual TLS is for how that extra step changes the message flow.

Can a handshake succeed and the connection still not be trustworthy?

Yes, in one case: if the client trusts a certificate authority it should not, for example a corporate inspection proxy or malware that installed a rogue root certificate, the handshake completes normally while a third party reads the traffic in the middle. The handshake only guarantees the two parties who negotiated hold matching keys, not that the client's trust store is clean.

What actually goes wrong when a handshake fails?

Version mismatches, no shared cipher suite, an expired or wrong-hostname certificate, a missing intermediate certificate, and SNI problems on shared hosting account for nearly every real-world failure. SSL handshake failed: causes and how to diagnose it covers each one with the exact commands to tell them apart.

Does a faster handshake actually matter for page speed?

Yes, especially on a slow or high-latency connection, since every extra round trip adds a full network delay before the first byte of the page can arrive. That is why TLS 1.3's drop from two round trips to one, and 0-RTT's drop to zero for repeat visitors, counted as major wins rather than small cleanups.