The TLS Handshake: How Your Browser Sets Up a Secure Connection

The Opening Exchange: ClientHello and ServerHello

The handshake begins the moment your browser opens a connection to a web server. It sends a message called the ClientHello, which lists the TLS versions and cipher suites (combinations of encryption, key exchange, and hashing algorithms) that the browser is capable of using, along with a randomly generated number. This random value is not decorative; it will later be mixed into the formula that produces the session's encryption keys, ensuring that no two connections ever end up with the same key even if everything else about the session looks identical. The server responds with a ServerHello. It picks one cipher suite from the browser's list, the one it considers strongest and that it also supports, and generates its own random number. At this point neither side has agreed on any secret information, they have simply agreed on the rules of the conversation. The server also attaches its digital certificate at this stage, setting up the next critical phase. This entire opening round trip is brief, but it is the foundation that every later cryptographic step depends on, since the negotiated cipher suite determines exactly which key exchange and encryption algorithms will be used for the rest of the handshake and the whole session.

Trusting a Stranger: Certificate Verification and the Chain of Trust

Agreeing on encryption algorithms means nothing if you are encrypting data for an impostor, so the browser must confirm that the server is who it claims to be. The server's certificate contains its domain name, its public key, and a digital signature from a Certificate Authority (CA). The browser checks that signature against a built-in list of CAs it already trusts, the same way you might trust a new document because a notary you already know stamped it. Often the signing CA is not itself in the browser's trusted list, but an intermediate authority, so the browser walks up a chain of trust from the server's certificate to an intermediate certificate to a root certificate that is baked into the operating system or browser. If every link in that chain checks out, and the certificate has not expired or been revoked, and the domain name matches the site being visited, the browser accepts the identity claim. If any of that fails, you get the familiar warning page telling you the connection is not private. This step matters because it is the only part of the handshake that defends against a stranger simply pretending to be your bank; without it, encryption alone would happily protect a conversation with an attacker.

Key Exchange and Forward Secrecy

Once the browser trusts the server's identity, both sides need to agree on a shared secret they can use for actual encryption, without ever sending that secret in the clear over the network. This is where public-key cryptography earns its keep. In modern TLS 1.3, this is almost always done with Diffie-Hellman or, more specifically, Elliptic-Curve Diffie-Hellman (ECDHE). Each side generates a temporary key pair just for this one session, exchanges the public halves, and combines them mathematically with its own private half to independently arrive at the identical shared secret, one that nobody eavesdropping on the exchange can reconstruct. The crucial word is ephemeral: because these key pairs are freshly generated per session and thrown away afterward, they are unrelated to the server's long-term certificate private key. That gives TLS 1.3 a property called forward secrecy: even if an attacker later steals the server's permanent private key, they cannot go back and decrypt session traffic they recorded months earlier, because the key that actually protected that traffic never existed anywhere except briefly in each side's memory during that one handshake.

Why Switch to Symmetric Encryption for the Real Data

Everything described so far, the certificate checks and the Diffie-Hellman exchange, relies on asymmetric cryptography, which is mathematically expensive and relatively slow because it involves large-number operations like modular exponentiation or elliptic-curve point multiplication. Using that for every byte of a video stream or a large file download would be impractical. So the handshake exists purely to bootstrap something simpler: a shared symmetric session key. Once both sides have derived that key through the exchange above, they switch to a symmetric cipher, most commonly AES (or the newer ChaCha20), where the same key both encrypts and decrypts data. Symmetric algorithms are dramatically faster, often by orders of magnitude, and are well suited to encrypting a continuous stream of data in real time. This division of labor is the pattern behind almost all practical encrypted communication: use slow, powerful asymmetric cryptography briefly to solve the hard problem of secure key agreement between strangers, then hand off to fast symmetric cryptography for the actual bulk workload of the session, which is why encrypted web browsing feels essentially as fast as unencrypted browsing did decades ago.

Fewer Round Trips: How TLS 1.3 Sped Things Up

Older TLS 1.2 handshakes typically required two full round trips between browser and server before any application data could be sent: one round trip to agree on the cipher suite and exchange randoms, and a second round trip dedicated to the key exchange and cipher-change confirmation messages. Each round trip costs real time, especially on high-latency mobile connections, and that delay was paid on every new connection. TLS 1.3, standardized in 2018, redesigned the flow to be far leaner. It merges the negotiation and key exchange into a single round trip: the ClientHello now includes the client's guessed key exchange parameters (its ECDHE public value) alongside its cipher suite list, so the server can respond with the ServerHello, its certificate, and the derived key confirmation all at once. This is often called a 1-RTT handshake, cutting the setup latency roughly in half compared to TLS 1.2. TLS 1.3 also introduced an even faster 0-RTT resumption mode for sites you have visited before, letting the browser send early application data in its very first message, at the cost of slightly weaker replay protection for that early data. TLS 1.3 additionally removed older, weaker cipher options entirely, which simplified the protocol and closed off entire categories of downgrade attacks that had plagued TLS 1.2.

Frequently asked questions

Try it live

Everything above runs in your browser — open The TLS Handshake: How Your Browser Sets Up a Secure Connection and change the parameters while it is running. Nothing is installed, nothing is uploaded, the whole model lives in one tab.