TLS Handshake Walkthrough Lab
Most people can name the TLS messages but cannot say what order they go in, what each one proves, or where an attacker leans on them. Walk the TLS 1.2 and TLS 1.3 handshakes message-by-message: sequence each flight, match every message to its purpose, and pin each attack — downgrade, MITM, renegotiation, RSA without forward secrecy, 0-RTT replay — to the message it hits and the defense that stops it. See exactly why 1.3 is faster and safer.
The real job. More noise, a tighter clock.
1 · Order the handshake (arrange each flight top-to-bottom)
TLS 1.2 handshake
Two round-trips: the server sends its certificate and key-exchange params, the client replies, then both sides confirm with Finished. RSA or (EC)DHE key exchange.
TLS 1.3 handshake (1-RTT)
One round-trip: the client guesses a key_share in the ClientHello, the server answers with its own in a single encrypted flight, and application data flows after the client Finished. Only (EC)DHE — no RSA key transport.
client sent · server sent
2 · What does each message do? (match to its purpose)
3 · Where does the attack hit? (pick the vulnerable point and the defense)
Protocol downgrade
A man-in-the-middle tampers with the ClientHello, stripping out the modern versions and strong ciphers so the connection falls back to SSLv3/export-grade crypto the attacker can break (POODLE/FREAK-style).
MITM without cert validation
A client does not validate the server certificate (or accepts any CA). An on-path attacker presents its own self-signed certificate and transparently proxies the whole session.
RSA key exchange, no forward secrecy
The server negotiates classic RSA key transport. An attacker records the encrypted traffic today, then compromises the server private key months later and decrypts every captured past session.
Renegotiation injection
An attacker opens a TLS session, sends a chosen plaintext prefix, then splices the victim’s new handshake in via renegotiation so the server treats attacker and victim data as one authenticated stream (CVE-2009-3555).
Stale session-ticket key
A load balancer encrypts resumption tickets with a static key that is never rotated. An attacker who later recovers that key can decrypt the resumption secrets and all sessions resumed with those tickets.
4 · TLS 1.2 vs 1.3
Select only the statements that are true of TLS 1.3.
Live score
Work the four challenges, then grade. So far 8% overall.
How it is graded
Four equally-weighted challenges: ordering both handshakes, matching each message to its purpose, pinning every attack to its point and defense, and identifying what TLS 1.3 changed. Clear 80% overall to pass; finish under par for a speed bonus and a better grade.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based lab that teaches the TLS handshake message-by-message — ClientHello, ServerHello, Certificate, ServerKeyExchange, CertificateVerify, Finished — for both TLS 1.2 and TLS 1.3.
- Four graded challenges: order the handshake for each version, match every message to its purpose, pin each attack to the message it hits and the defense that stops it, and identify what TLS 1.3 removed and improved.
- See why 1.3 is 1-RTT: the client sends a key_share in the ClientHello and the server answers the certificate, CertificateVerify and Finished in one encrypted flight.
- Attack scenarios cover downgrade (TLS_FALLBACK_SCSV), MITM without cert validation, renegotiation injection, RSA key exchange vs (EC)DHE forward secrecy, and 0-RTT replay.
- Difficulty tiers add the subtler scenarios — session-ticket reuse, 0-RTT replay and the resumption/forward-secrecy nuances — and tighten the clock.
Frequently asked questions
What is the TLS Handshake Walkthrough Lab?
A free, in-browser exercise that walks through the TLS handshake one message at a time for both TLS 1.2 and TLS 1.3. You order the messages into the correct sequence for each version, match each message to the job it does (negotiation, key exchange, authentication, integrity, resumption), identify where each classic attack lands and the defense that stops it, and pick out what TLS 1.3 changed. It grades your answers and explains every miss.
How is TLS 1.3 different from TLS 1.2?
TLS 1.3 cuts the full handshake to one round-trip (1-RTT), and to zero round-trips on resumption (0-RTT). It removed RSA key transport and static Diffie-Hellman, so every connection uses ephemeral (EC)DHE and has forward secrecy. It removed renegotiation, dropped weak ciphers and MD5/SHA-1, and encrypts the handshake much earlier — the certificate and extensions are sent encrypted after ServerHello. The trade-off is that 0-RTT early data can be replayed, so it is unsafe for non-idempotent requests.
Which attacks does it cover?
Protocol/cipher downgrade (defended with TLS_FALLBACK_SCSV and dropping old versions), man-in-the-middle when certificate validation is skipped (strict chain/name validation, CT, pinning), RSA key exchange having no forward secrecy versus ephemeral (EC)DHE, renegotiation injection (RFC 5746 secure renegotiation, or TLS 1.3 which removed renegotiation), stale session-ticket keys, and TLS 1.3 0-RTT replay.
Is this a real TLS stack?
No. It is a teaching model of the handshake message flow and where attacks hit. It deliberately simplifies the exact byte-level exchange so the lesson — what each message proves and where an attacker can lean on it — is clear. Everything runs in your browser; no account, no install, nothing sent to a server.