How the HTTPS Handshake Actually Works

Ask most engineers how HTTPS works and you get some version of: the server sends a certificate, the browser checks it, then everything is encrypted.

That's the identity half, and it's the less interesting half. The certificate proves who you're talking to. It doesn't get you a shared key.

The real problem TLS solves is stranger than that. Two machines that have never communicated before need to agree on a secret encryption key — while every byte they exchange is visible to anyone on the path. No prior arrangement. No side channel. Everything in the open.

That should be impossible. Here's how it isn't.

The problem, stated plainly

You and a server need the same secret number. You've never met. An attacker records the entire conversation.

If you send the secret, the attacker has it. If the server sends it, same. Encrypting it first requires a key you don't yet share. This looks circular, and for most of computing history it was solved by shipping keys around physically.

The escape is a piece of math where you can each send something public, and each independently compute a shared value that no observer can reconstruct from what crossed the wire. The secret is never transmitted. It's derived, twice, in two places.

Diffie-Hellman, without the math

The standard intuition uses paint, and it holds up.

You and the server publicly agree on a common color — everyone can see it, it's not secret. Then you each privately pick a second color and keep it to yourself. You mix your private color into the common one and send the result. The server does the same and sends theirs.

Now you take the mixture you received and add your private color. The server takes your mixture and adds its private color. Both of you end up holding the identical combination of all three colors.

An observer saw the common color and both mixtures. To reach what you now share, they'd need to un-mix a color out of a mixture — and that's the trick, because mixing is easy and separating is not.

Real TLS uses elliptic curve arithmetic instead of paint. The one-way property is the same: computing the public value from the private one is fast, and going backwards is computationally infeasible. Each side combines its own private key with the other side's public share, and the arithmetic guarantees both arrive at the same number.

That number becomes the session key. It was never sent.

The handshake, step by step

Client hello. The client opens with a random value, the list of cipher suites it supports, the TLS versions it speaks, and — this is the TLS 1.3 change that matters — a key share, guessed optimistically before knowing what the server wants.

That last part is why TLS 1.3 is fast. Older versions negotiated parameters first and exchanged keys after, costing two round trips before any real data moved. TLS 1.3 gambles on the most likely parameters, sends the key share immediately, and is usually right.

The hello also carries SNI — the hostname being requested, in plaintext, because the server may host hundreds of sites on one IP and needs to know which certificate to present. It's the one meaningful piece of metadata still visible to observers, which is why Encrypted Client Hello exists as an ongoing effort to close it.

Server hello. The server picks a cipher suite from what the client offered, sends its own random value, and sends its own key share.

Both sides derive the secret. No message. This is local computation on each end, and it's the moment the connection becomes private. Everything after this point is encrypted.

Certificate and signature. Only now does the server prove who it is — and it does so under encryption, which older TLS versions couldn't. It sends its certificate chain and, critically, a signature over the entire handshake transcript so far.

That signature is the part people skip. The certificate alone proves the server possesses a public key some authority vouched for. The signature proves it also holds the matching private key and has been party to this specific conversation. Without it, anyone could replay a copy of a valid certificate.

Client verifies. The browser walks the chain: this certificate was signed by that intermediate, which was signed by a root your operating system already trusts. It checks expiry, checks the hostname matches, checks revocation status.

Application data. Your actual HTTP request finally goes out — one round trip after the connection opened.

Where the trust actually comes from

The chain terminates at root certificates preinstalled in your OS and browser. Those roots aren't verified by anything — they're trusted by declaration. Your device ships with roughly 150 of them and treats them as axioms.

This is the honest weak point of the whole system. Any one of those authorities can issue a certificate for any domain. A compromised or coerced CA can mint a valid certificate for your bank, and the math will check out perfectly, because the math was never the thing being trusted.

Certificate Transparency exists because of this. Every issued certificate is logged publicly and append-only, so a domain owner can monitor for certificates they never requested. It doesn't prevent bad issuance — it makes it detectable after the fact. Which is a weaker guarantee than most people assume they have.

Forward secrecy, and why the ephemeral part matters

In older TLS, the client could encrypt a secret using the server's long-term public key from its certificate. Simple, and catastrophic in one specific way: an attacker who recorded years of traffic and later obtained the server's private key could decrypt all of it retroactively.

Modern TLS generates a fresh key pair for every single connection. The certificate's key is used only to sign, proving identity — never to encrypt the session secret. When the connection closes, the ephemeral keys are discarded and the session key is unrecoverable.

Compromise the server tomorrow and yesterday's captured traffic stays opaque. That's forward secrecy, and it's why TLS 1.3 removed the non-ephemeral options entirely rather than leaving them configurable.

What this is worth knowing

The handshake is a working example of things that are otherwise abstract: establishing a shared secret over a public channel, separating identity from confidentiality, and building a trust chain that terminates in something you simply decided to believe.

It's also directly practical. Understanding that SNI is plaintext explains why hostnames leak. Understanding the signature-over-transcript explains why certificate pinning works. Understanding forward secrecy explains why "we rotated the key after the breach" is not the reassurance it sounds like.

The one-line summary

TLS separates two problems — agreeing on a secret and knowing who you're agreeing with. The certificate solves the second one. The key exchange, which is the part nobody explains, solves the first.

Next in this series: How caching actually works — and why cache invalidation earned its reputation.

I'm a senior software engineer working across distributed backends, cloud infrastructure, and event-driven systems. I write one of these breakdowns each week. If you're building something in this space — or hiring for it — I'd like to hear from you.