The idea in plain English: When you visit a website with https:// in
the URL, your browser and the server perform an elaborate cryptographic dance called the
TLS handshake before a single byte of your data is sent. The goal is deceptively
simple: agree on a shared secret key, verify the server's identity, and
set up a secure tunnel — all within about 100–300 milliseconds.
Think of it like meeting a stranger in a dark room. You need to: (1) confirm they are who they say they are, (2) agree on a secret code word that only you two know, and (3) make sure nobody else can listen in. All of this happens before you say anything private. That's the handshake.
Why this really exists: Before TLS, HTTP traffic was sent in plain text over the network. Anyone on the same Wi-Fi network, any ISP, any router in between could read every password, credit card number, and private message. TLS solved this by adding a cryptographic handshake layer between HTTP and TCP. Today, over 95% of all web traffic uses HTTPS — the lock icon in your browser is powered by TLS. Without it, e-commerce, online banking, and private communication would be impossible at scale.
1. ClientHello — The browser sends its supported cipher suites, a random number (client_random), and the highest TLS version it can handle. This is the opening move.
2. ServerHello — The server picks one cipher suite from the client's list, sends its own random number (server_random), and confirms the TLS version. The two sides now agree on what crypto they'll use.
3. Certificate — The server sends its X.509 certificate chain, which includes its public key (often an ECDSA or RSA key). The client verifies the certificate against a trusted CA (Certificate Authority) — this proves the server is who it claims to be.
4. ServerKeyExchange — For key exchange algorithms like ECDHE or DHE, the server sends its ephemeral Diffie–Hellman parameters (public value, curve, signature). This is what enables forward secrecy: even if the server's long-term key is later stolen, past sessions stay secure.
5. ServerHelloDone — The server signals: "I'm done with my part — your turn."
6. ClientKeyExchange — The client sends its ephemeral DH public value. Both sides now compute the pre-master secret using ECDH: shared_secret = ECDH(client_priv, server_pub) = ECDH(server_priv, client_pub).
7. ChangeCipherSpec + Finished — The client announces it's switching to encrypted mode, then sends an encrypted "Finished" message (a hash of the entire handshake). The server responds with its own ChangeCipherSpec + Finished. Both sides verify the hashes match — if they do, the handshake is complete.
Total messages: ~7 round trips (TLS 1.2). TLS 1.3 reduces this to 1 round trip (or 0 with session resumption) by combining steps.
The pre-master secret (from ECDH) is never used directly to encrypt data. Instead, both sides feed it into a Pseudo-Random Function (PRF) along with the client_random and server_random to derive multiple session keys:
The PRF ensures that every session gets unique keys, even if two sessions happen to produce the same pre-master secret (astronomically unlikely, but defense-in-depth).
In this puzzle website, you'll be given a partial TLS handshake transcript. Some value in the handshake is missing or obfuscated — you must reconstruct it from the other values, using the same key derivation logic that real TLS implementations use.
The puzzle may use a simplified PRF (like repeated HMAC-SHA256) rather than the full TLS PRF. The core logic — seeded derivation from shared secret + randomness — is the same.