TLS Handshake
Type https:// and your browser runs a whole conversation before the first HTTP byte leaves: a second round of messages that agrees a key nobody sent and proves the server is who it claims. Read what crosses the wire.
- ▸Every
https://runs a second handshake before your first request, and TLS 1.3 fits it into a single round trip. - ▸The session key is never sent: each side derives it, and an eavesdropper with both public halves still can't.
- ▸Showing a certificate proves nothing; only a signature made with the matching private key does.
You already know the TCP three-way handshake: SYN, SYN-ACK, ACK, and the connection reaches ESTABLISHED. On an http:// URL, the very next thing on the wire is your request line. On an https:// URL, it is not.
Between ESTABLISHED and the first HTTP byte, a second exchange runs end to end. It agrees on how to encrypt, works out a shared key, and checks the server's identity, all before your GET / is allowed to travel. Nothing at the HTTP layer moves until that exchange completes.
That pins the exchange to a specific spot: above TCP, which carries its messages, and below HTTP, which waits for it. TCP moved bytes without caring what they were. This layer decides those bytes will be unreadable to anyone watching, and that the machine on the other end is the one you dialed.
Order the phases of a single https:// fetch and see where the first GET can finally go. The connection opens, the second exchange runs, and only then does HTTP speak.