HTTPS — TLS handshake, certificates, CA: Visual walkthrough

We are solving one puzzle: two computers who have never met must end up sharing one secret code, over a wire that everyone can read, while being sure they are talking to the right partner.

Step 1 — The naked wire (the problem we must beat)

WHAT. Draw the situation before any cleverness. A client (your laptop) and a server (bank.com) are joined by a wire. On that wire sits Eve, who can read every byte, change every byte, and even pretend to be the server.

WHY. You cannot design a defence until you can see exactly what the attacker can do. Everything we build later is a direct answer to one of Eve's three powers.

PICTURE. The wire carries plain words "PASSWORD = hunter2" and Eve reads them in the clear. Notice the wire runs on top of an already-open TCP connection — TLS never builds the pipe, it only secures whatever pipe TCP gave it.

Figure — HTTPS — TLS handshake, certificates, CA

Step 2 — First idea: just encrypt with a shared key (and why it fails alone)

WHAT. Suppose client and server already shared one secret key $k$ . Then everything is easy: the client scrambles the message with $k$ (this is symmetric encryption, one key both scrambles and unscrambles), and Eve sees only gibberish.

WHY. Symmetric encryption (like AES) is fast — perfect for the megabytes of a web page. This is why TLS will always end up using it for the bulk data.

PICTURE. Same wire as Step 1, but now the plaintext passes through a lock labelled $k$ and comes out as noise. Eve reads the noise and learns nothing.

The catch. We assumed both sides already share $k$ . They have never met. If the client tries to send $k$ over the wire, Eve reads it in Step-1 conditions. So the whole puzzle collapses to one question: how do two strangers agree on a secret over a public wire? That is the next step. (See Symmetric vs Asymmetric Encryption for why we can't just use symmetric everywhere.)

Step 3 — Agreeing on a secret in public: Diffie–Hellman

WHAT. Here is the trick that feels like magic. Both sides publicly agree on two numbers: a big prime $p$ and a base $g$ . The client secretly picks a number $a$ and sends $A = g^{a} mod p$ . The server secretly picks $b$ and sends $B = g^{b} mod p$ . Now each raises the other's number to its own secret — and they land on the same value.

WHY this exact tool. We need an operation that is easy forwards but hard backwards. Raising to a power mod $p$ is that operation: computing $g^{a} mod p$ is quick, but recovering $a$ from $g^{a}$ is the discrete logarithm problem — believed impossibly slow for big $p$ . That one-way property is why Diffie–Hellman works and why we don't use ordinary multiplication (which is easy to reverse).

PICTURE. Two mixing bowls. Client and server start from the same public paint $g$ , each stirs in their private paint ( $a$ or $b$ ), swap the mixed bowls, then stir in their own private paint again. Both bowls end the same colour $g^{ab}$ . Eve saw the two swapped bowls but can't un-mix them.

So Step 2's "assume they share $k$ " is now earned: Diffie–Hellman manufactures $k$ in public. Full detail lives in Diffie–Hellman Key Exchange.

Step 4 — The hole that remains: who is on the other end?

WHAT. Diffie–Hellman defeats eavesdropping — but not impersonation. Eve can run DH twice: she does a handshake with you pretending to be the server, and a separate handshake with the real server pretending to be you. She sits in the middle, decrypting and re-encrypting. This is the man-in-the-middle (MITM) attack.

WHY it matters. A shared secret is worthless if you shared it with the wrong person. We beat eavesdropping in Step 3; now we must beat impersonation. Confidentiality without authentication is hollow.

PICTURE. The wire is cut in the middle by Eve. She holds two separate DH secrets — one with the client, one with the server — and relays messages, reading everything as it passes through her.

The fix must let the client verify that the DH share $B$ truly came from bank.com and not Eve. For that we need a way to prove identity and a way to prove a message wasn't swapped — the next two steps.

Step 5 — Signatures: proving a message came from a specific someone

WHAT. Introduce asymmetric keys: a pair — a private key $K^{-}$ kept secret, and a public key $K^{+}$ handed to the world. The magic: only $K^{-}$ can create a signature, but anyone with $K^{+}$ can check it. To sign, the server first shrinks the message with a hash (a one-way fingerprint, e.g. SHA-256), then locks that fingerprint with $K^{-}$ .

WHY a hash, and why asymmetric here. We hash first because signing a tiny fixed-size fingerprint is cheap and any change to the message changes the fingerprint (that gives us integrity). We use asymmetric keys because we need "only one specific party can produce it, everyone can verify it" — symmetric keys can't do that (a shared key means both sides could forge). See Digital Signatures & Hashing.

PICTURE. The server hashes its DH share $B$ to a short fingerprint, seals it with the private key into a signature $σ$ . The client re-hashes $B$ itself and uses the public key to check the seal. Match ⇒ genuine; mismatch ⇒ tampered or forged.

But a new gap opens: how does the client know that $K^{+}$ belongs to bank.com? Eve could send her own public key. Step 6 closes this last loop.

Step 6 — Certificates & the chain of trust

WHAT. A certificate is a small document saying "public key $K^{+}$ belongs to bank.com", itself signed by a Certificate Authority (CA) using the CA's private key. Your browser ships with a trust store of CA root public keys baked in at install time. Verifying a cert is just running Step 5's Verify with the CA's public key.

WHY a third party. The client has no prior relationship with bank.com, but it does trust the CA (baked in). Trust is transitive through signatures: the root vouches for an intermediate, the intermediate vouches for the leaf bank.com. Following signatures up to a root you already trust is the chain of trust. Details in Public Key Infrastructure (PKI).

PICTURE. A staircase of three cards: leaf (bank.com), intermediate, root. Each card's signature is checked with the public key on the card above it, until the top card matches a root already sitting in the browser's trust store.

Step 7 — Freshness & transcript binding (the last polish)

WHAT. Two loose ends. (a) If keys were derived from the DH secret alone, a recorded old session could be replayed. So each side also throws in a fresh random nonce ( $r_{c}$ from the client, $r_{s}$ from the server) that seasons the key. (b) The early messages (ClientHello, cipher list) went out before encryption started — Eve could have downgraded them. So each side sends a Finished message: a MAC computed over the entire transcript so far.

WHY. The nonces guarantee freshness — the same password gives different keys every session, killing replay. The Finished MAC guarantees the negotiation itself wasn't tampered with: if Eve edited any earlier byte, the two transcripts differ and the Finished check fails.

PICTURE. A funnel: pre-master secret $+ r_{c} + r_{s}$ all pour into a one-way box labelled $PRF$ , out come the session keys. Below, both transcripts are hashed and compared — equal means "no tampering, switch on encryption".

The one-picture summary

Every arrow below is one enemy defeated. Read it top to bottom: the raw wire, then each defence stacked on the one before it, ending in the fast symmetric tunnel carrying real HTTP data.

Recall Feynman: the whole walkthrough in plain words

Two strangers want to whisper across a crowded, pickpocket-filled street. First they realise a secret code would fix everything (symmetric encryption) — but they've never met, so they have no code yet. So they play a paint-mixing game in full view: each stirs in a private colour, swaps bowls, stirs again, and — amazingly — both bowls end up the same colour that watchers can't reproduce (Diffie–Hellman). That shared colour becomes their code. But a clever pickpocket could stand in the middle mixing paint with each of them separately. To stop that, the shopkeeper shows an ID card signed by a mayor the stranger already trusts (certificate signed by a CA), and signs the paint bowl so no one can swap it (digital signature). The stranger checks the mayor's stamp — real shopkeeper confirmed. Finally they sprinkle in fresh random numbers so today's code differs from yesterday's, and each repeats back everything they heard to be sure nobody edited the greeting (nonces + Finished). Only then do they start whispering in their fast secret code. The pickpockets see gibberish.

Recall Quick self-check

Which enemy does Diffie–Hellman NOT defeat by itself? ::: Impersonation (MITM) — it defeats eavesdropping only; you still need certificates/signatures for authentication. Why hash the message before signing? ::: Signing a small fixed-size fingerprint is cheap, and any change to the message changes the fingerprint, giving integrity. What makes keys different every session? ::: The fresh random nonces $r_{c}$ and $r_{s}$ mixed into the PRF (plus ephemeral DH values for forward secrecy).