What the Handshake Actually Agrees
Versions, cipher suites, ALPN — and what happens when there is no overlap
Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.
What you'll be able to do
- ▸List what a TLS handshake negotiates, beyond the certificate
- ▸Explain why version negotiation is a floor rather than a preference
- ▸Describe forward secrecy and resumption in terms of what each protects
Before a client and a server can protect anything, they have to agree how — and they have to do that agreeing over a channel that is not yet protected, in front of anyone watching.
That is the hard part of TLS and the reason the handshake looks the way it does. Everything in the opening messages is readable, because there is no key yet. The agreement has to survive being watched, and it has to survive being tampered with by somebody who would prefer the two ends chose something weaker.
- 1The client offers: a version, a list of cipher suites, the server name, an ALPN list, and in 1.3 a key share.
- 2The server chooses one version and one cipher suite from what it can do — or ends the conversation if there is no overlap.
- 3The server sends its own key share, so both sides can now derive the same secrets.
- 4The server presents its certificate; the client validates the name, the chain and the dates.
- 5Both send a Finished message covering the whole handshake, so any tampering with the earlier messages is detected.
- 6Only now does application data flow.
✓ Concept check — before you open the packets
These test the idea, not the trace. You should be able to answer them from the explanation above.
Now that you understand the concept, observe how it appears in the packet exchange.
The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.