The TLS 1.2 Handshake

We've now seen all the pieces — symmetric and asymmetric encryption, MACs and AEAD, certificates and the chain of trust. Time to watch them work together. This is the TLS 1.2 handshake, which still runs about a quarter of HTTPS traffic in 2026. Next section we'll see how TLS 1.3 makes it faster and simpler — but to appreciate the speedup, you need to see what came before.

The Goal — Agree On A Symmetric Key With A Stranger

Remember the architecture: TLS uses asymmetric crypto to agree on a shared secret, then switches to symmetric crypto for the actual data. The handshake is the asymmetric-crypto part. Everything from "Hi" to "now we can talk privately" happens in just a few round trips.

By the end of the handshake, both client and server must:

• Be sure they're talking to each other (authentication via certificate);
• Agree on which cipher suite to use;
• Derive a shared symmetric key that no eavesdropper could possibly have.

Here's how, in six acts.

Act 1 — ClientHello

Maria's browser opens a TCP connection to port 443 and immediately sends a ClientHello message. It contains:

• TLS versions supported — e.g., "I can speak TLS 1.0 through 1.3";
• Cipher suites supported — a list, in order of preference;
• A random number — 32 bytes of client randomness;
• Server name (SNI) — the domain being requested, e.g., yourbank.com (in plaintext, more on this in Section 3);
• Extensions — supported curves, signature algorithms, ALPN protocols, etc.

The browser is shouting, in the open: "Hi, here's what I can do, here's who I want to talk to."

Act 2 — ServerHello + Certificate + ServerKeyExchange + ServerHelloDone

The server replies with a bundle of messages:

• ServerHello — "I pick TLS 1.2, and from your list I pick this cipher suite: ECDHE-RSA-AES256-GCM-SHA384. Here's my own 32 bytes of randomness";
• Certificate — the server's certificate chain (leaf + intermediate, sometimes the root too);
• ServerKeyExchange — the server's ephemeral Diffie-Hellman public key, signed with the server's certificate private key. This is the magic step that enables Perfect Forward Secrecy (see Section 2);
• ServerHelloDone — "I'm done talking for now."

Act 3 — Client Verifies The Certificate

Before sending another byte, Maria's browser does the most important work of the handshake:

• It walks the certificate chain from leaf to root;
• It checks that the root is in the trust store;
• It checks the certificate is not expired;
• It checks the certificate's Subject or Subject Alternative Name matches yourbank.com;
• It checks the certificate hasn't been revoked (OCSP — covered in Section 2);
• It verifies the ServerKeyExchange signature using the leaf's public key.

If any of these fail, the connection dies with a scary error. This is the authentication step — the entire reason certificates exist.

Act 4 — ClientKeyExchange + ChangeCipherSpec + Finished

Assuming the cert checks out, the browser:

• Computes its own ephemeral Diffie-Hellman public key;
• Sends it in ClientKeyExchange;
• Both sides now perform the Diffie-Hellman calculation to derive a shared secret. This is the moment the symmetric key is born — never transmitted across the wire, just computed independently by each side from values they exchanged;
• Sends ChangeCipherSpec ("everything after this is encrypted");
• Sends Finished — encrypted with the new symmetric key, containing a hash of the entire handshake so far. This proves the browser has the right key and that no message in the handshake was tampered with.

Act 5 — Server Sends Its Finished

The server decrypts the Finished message with its derived symmetric key. If it decrypts correctly and the handshake hash matches, the server knows everything went right. It sends its own ChangeCipherSpec and Finished in return.

Act 6 — Application Data Flows

From this point on, every byte is encrypted with the symmetric key. The browser sends the actual HTTP request. The server replies with the actual HTTP response. The expensive part is over.

The Big Picture — How Many Round Trips?

Count the back-and-forth:

• Round 1 — Client sends ClientHello. Server replies with ServerHello + Certificate + KeyExchange + HelloDone;
• Round 2 — Client sends ClientKeyExchange + ChangeCipherSpec + Finished. Server replies with ChangeCipherSpec + Finished;
• Round 3 — Client finally sends the actual HTTP request. Server replies.

That's two full round trips before any application data flows. Add TCP's own 1-RTT setup (the SYN-SYNACK-ACK handshake), and you're at 3 RTTs before the first byte of HTML arrives. For a user in Berlin talking to a server in São Paulo (around 200ms one way), that's 1.2 seconds of pure handshake time before the page even starts loading.

This is the inefficiency TLS 1.3 was built to fix. We'll see how next section.