The handshake, step by step

Before encrypted bytes can flow, both sides must agree on a protocol version, choose algorithms, authenticate the server, and derive identical keys. The handshake is that negotiation. Its cost is round trips, and the history of TLS is largely a story of removing them.

1. 1

   ClientHello

   The client sends supported versions, a list of cipher suites, a random value, the SNI hostname, and one or more key shares for guessed key-exchange groups.

2. 2

   ServerHello

   The server picks a version, a cipher suite and a key share, and replies with its own random value.

3. 3

   Derive handshake keys

   Both sides combine the key shares to compute a shared secret, then expand it into handshake keys. Everything after this point is encrypted.

4. 4

   Encrypted extensions and certificate

   The server sends its certificate chain and proves key ownership by signing a hash of the handshake transcript.

5. 5

   Verify

   The client validates the chain against its trust store, checks the name, and verifies the signature.

6. 6

   Finished

   Each side sends a MAC over the whole transcript. Both now share application keys; HTTP can start.

• The certificate and ServerHello were sent in clear, so the certificate was visible to observers
• Key exchange was often RSA: the client encrypted a secret to the server's public key, so there was no forward secrecy
• The full handshake took two round trips before application data
• Many weaker options (CBC-mode ciphers, static RSA, SHA-1) were permitted and had to be disabled by configuration

TLS 1.3 removed the weak options rather than asking operators to turn them off. That is a good pattern to remember: protocol design can enforce security better than documentation can.

After a connection closes, the client can hold a ticket that lets a later connection skip the certificate exchange. That is session resumption. It saves a round trip and, importantly on mobile networks, real latency.