← Back to Table of Contents

The Full TLS 1.2 Handshake

This is the deep dive. We’re going to walk through every message in the TLS 1.2 handshake, what it contains, and why it’s needed. By the end of this chapter, you’ll understand exactly what happens in those milliseconds between typing a URL and seeing a page.

The Two Round Trips

Think of the handshake like two people meeting for the first time at a business conference. In the first exchange, they introduce themselves and show their business cards. In the second exchange, they agree on a private code to use for the rest of the conversation. Only after both exchanges are complete can they start talking business.

The TLS 1.2 handshake requires two full round trips before encrypted data can flow. The following diagram shows every message in order:

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: Round Trip 1
    C->>S: 1. ClientHello
    S->>C: 2. ServerHello
    S->>C: 3. Certificate
    S->>C: 4. ServerKeyExchange
    S->>C: 5. ServerHelloDone

    Note over C,S: Round Trip 2
    C->>S: 6. ClientKeyExchange
    C->>S: 7. ChangeCipherSpec
    C->>S: 8. Finished
    S->>C: 9. ChangeCipherSpec
    S->>C: 10. Finished

    Note over C,S: Encrypted Application Data
    C->>S: HTTP Request (encrypted)
    S->>C: HTTP Response (encrypted)

ClientHello

The client initiates the handshake. The ClientHello contains:

• Client Random: 32 bytes of random data. Used later in key derivation. This randomness ensures every session produces different keys.
• Session ID: If the client has connected to this server before, it sends the previous session ID to attempt resumption. Empty for new connections.
• Cipher Suites: An ordered list of cipher suites the client supports. The server will pick one.
• Compression Methods: Always “null” (no compression). Compression was removed because of the CRIME attack.
• Extensions: Additional data like SNI (which hostname the client wants), supported signature algorithms, supported elliptic curves, and more.

The ClientHello is sent in plain text. An eavesdropper can see everything in it, including the SNI (which reveals which website you’re connecting to).

ServerHello

The server responds with its choices:

• Server Random: 32 bytes of random data from the server.
• Session ID: A new session ID (or the same one if resuming).
• Cipher Suite: The single cipher suite the server selected from the client’s list.
• Compression Method: Always null.
• Extensions: Server’s extension responses.

Certificate

The server sends its certificate chain: the server certificate plus any intermediate CA certificates. The client needs these to verify the server’s identity.

ServerKeyExchange

This message is only sent for cipher suites that use Diffie-Hellman key exchange (DHE or ECDHE). It contains:

• The server’s ephemeral DH public value (the server’s contribution to the key exchange)
• The DH parameters (which curve or group to use)
• A digital signature over the above values, signed with the server’s private key

The signature is critical. Without it, an attacker could substitute their own DH parameters and perform a man-in-the-middle attack. The signature proves the DH parameters came from the legitimate server.

For RSA key exchange (no DH), this message is not sent. The client encrypts the pre-master secret directly with the server’s RSA public key.

ServerHelloDone

A simple message that says “I’m done sending my hello messages.” The client now has everything it needs to proceed.

Client Verifies the Certificate

Before responding, the client validates the certificate chain: signature verification, validity period, domain match, revocation check, and trust chain. If any check fails, the handshake is aborted.

ClientKeyExchange

The client’s contribution to the key exchange:

• For ECDHE: The client’s ephemeral DH public value. Combined with the server’s value, both sides can compute the pre-master secret.
• For RSA: The client generates a random pre-master secret, encrypts it with the server’s RSA public key, and sends the encrypted value.

Pre-Master Secret to Master Secret

Both sides now have the pre-master secret (either computed via DH or exchanged via RSA). They combine it with the Client Random and Server Random to derive the master secret using the PRF:

master_secret = PRF(pre_master_secret, "master secret",
                    ClientHello.random + ServerHello.random)

From the master secret, they derive all the session keys: client write key, server write key, client write IV, server write IV, and MAC keys.

ChangeCipherSpec

Both sides send this message to signal: “From now on, everything I send will be encrypted with the keys we just derived.” It’s a single byte (0x01) in its own record.

Finished

The first encrypted message. It contains a hash of all handshake messages exchanged so far, encrypted with the new session keys. Both sides compute this hash independently.

If the hashes match, it proves:

1. Both sides derived the same keys (the encryption/decryption worked)
2. No one tampered with the handshake messages (the hash covers everything)

If an attacker modified any handshake message (like removing strong cipher suites from the ClientHello), the hashes won’t match, and the handshake fails.

Encrypted Data

After both Finished messages are verified, the handshake is complete. All subsequent data is encrypted with AES (or whatever bulk cipher was negotiated) using the session keys.

---

Next: The Ephemeral Diffie-Hellman Handshake

← Previous ChapterNext Chapter →