Two machines that have never spoken before need to agree on a secret. They're communicating over a network where anyone can read every packet. And they need to pull this off in a few milliseconds, before you notice the page loading slowly. That's the TLS handshake.
Every HTTPS connection starts with one. It's the reason your connections have a latency floor, and it's where most TLS misconfigurations live. I covered what HTTPS actually protects in a previous post. This one is the handshake itself, the message flow I promised would get its own post.
Before a single byte of application data moves, the handshake needs to accomplish three things:
Agree on a shared symmetric key. Both sides need an identical secret to encrypt everything that follows, and that secret can't have crossed the wire in plaintext.
Confirm the server's identity. The client needs proof it's talking to the real server and not someone intercepting traffic. The server presents a certificate; the client verifies it. (How certificates actually work, X.509 fields, chains of trust, CAs, is a separate post that's coming.)
