Skip to content

09-01: Exercises

Question

Here are the main messages of a TLS 1.2-style handshake, listed out of order:

  • A. Finished (client)
  • B. ClientHello
  • C. ServerHello
  • D. Change Cipher Spec + session encryption begins
  • E. Certificate (server presents its certificate chain)
  • F. Key exchange material exchanged (e.g., ServerKeyExchange / client's key share)

  • G. Finished (server)

  • Put these in the correct order.

  • Give a one-line purpose for each message.

Solution

Step 1: Reconstruct the sequence

Recall the handshake's purpose (see 09-02: The TLS Handshake): the client and server need to (a) agree on capabilities, (b) authenticate the server (and optionally the client), (c) establish a shared secret, and (d) confirm both sides derived the same keys before sending real data.

That gives the order:

  1. B. ClientHello — client proposes supported TLS versions, cipher suites, and a random value.
  2. C. ServerHello — server picks a TLS version and cipher suite from the client's list, and sends its own random value.
  3. E. Certificate — server presents its certificate (and chain) so the client can authenticate it.
  4. F. Key exchange material — both sides exchange the values needed to compute a shared secret (e.g., Diffie-Hellman public values — see 07-05: Diffie-Hellman Key Exchange).
  5. D. Change Cipher Spec — both sides signal "from this point on, everything is encrypted with the negotiated keys."
  6. A. Finished (client) — the client sends a MAC over the entire handshake so far, encrypted with the new keys, proving it computed the same keys and that the handshake wasn't tampered with.
  7. G. Finished (server) — the server does the same in the other direction.

Step 2: One-line purpose per message

Order Message Purpose
1 ClientHello Propose supported versions/ciphers + a random value
2 ServerHello Select the version/cipher suite + server's random value
3 Certificate Let the client verify the server's identity (see 07-08: Digital Certificates & PKI)
4 Key exchange material Both sides derive the same shared secret without ever sending it directly
5 Change Cipher Spec Signal that all further messages are encrypted with the new session keys
6 Finished (client) Client proves it derived the correct keys and the handshake wasn't tampered with
7 Finished (server) Server proves the same thing back to the client

💡 As a side note covered in 09-01: TLS History & Versions, TLS 1.3 restructures and compresses this flow into fewer round trips — but the logical steps (negotiate → authenticate → key exchange → confirm) still all happen, just more efficiently.

Final Answer

Correct order: B → C → E → F → D → A → G (ClientHello → ServerHello → Certificate → key exchange → Change Cipher Spec → client Finished → server Finished)