The TLS Handshake

In the tenth of a second before this page appeared, your browser and a server it had never spoken to before agreed on a set of encryption keys, established that the server was genuinely the one named in the address bar, and did it all over a connection that any router along the way could read. If that sounds like it must involve something exotic, the pleasant surprise of this track is that it does not. A TLS 1.3 handshake is the Diffie-Hellman exchange you built in P52, with the server's contribution signed by the certificate you learned to verify in the previous track.

You will drive a stripped-down handshake to a shared secret in process — live network handshakes cannot run in the browser sandbox by design, so the simulation runs over the same mathematics — and then follow what happens to that secret. It is never used to encrypt anything directly. The key schedule expands it into separate keys for each direction and purpose, which is why compromising one does not hand over the others. Because a fresh secret is generated for every connection, recording today's traffic and stealing the server's private key next year still does not decrypt it: that property is forward secrecy, and here it is a consequence you can trace rather than a bullet point.

The track then turns to what an active attacker tries instead. If the cryptography is sound, the remaining move is to make one side agree to something weaker — an older protocol version, a downgraded cipher suite — or to insert themselves in the middle and hope nobody checks the certificate properly. You will see how the handshake is bound together so that tampering with the negotiation is detectable, and why the man-in-the-middle attack that defeated bare Diffie-Hellman in P52 now fails: the attacker can still run the exchange twice, but cannot produce a signature that chains to a root your client trusts.