About this interactive
The TLS handshake is usually met as a list of message names in a row — ClientHello, ServerHello, Certificate, CertificateVerify, Finished — and a student who can recite that list still cannot say what has to be true before any one of them can be sent, or which of them actually settles anything. Closing that gap is what this set is for, and it is why no card opens with its message name. Each card describes the mechanism and ends with what that step settles, so the vocabulary is attached to the behaviour rather than standing in for it. The chronology here is real rather than conventional, and two constraints do most of the work. The first is where the shared secret comes from. TLS 1.3 carries key shares in the opening two messages — the client sends one speculatively with its offer, the server returns one with its selection — so both sides can run Diffie-Hellman and derive the secret after the second flight. Everything from the third card onward is therefore encrypted, which is the single structural difference from TLS 1.2 that the rest of the sequence follows from: the certificate is no longer visible on the wire, and the session parameters that reveal which service and which application protocol the connection is for are no longer visible either. It is also why the handshake costs one round trip instead of two. The second constraint is that a proof cannot precede the thing it proves. CertificateVerify is a signature over a hash of the entire handshake transcript to that point, and Finished is a keyed hash over the same growing transcript; neither can be computed before the messages it covers have been sent. A student who sees that will never put CertificateVerify before Certificate, because the ordering stops being a convention to memorise and becomes a dependency. The Certificate and CertificateVerify pair is the other place the reasoning bites, and it is the distinction students most reliably lose. A certificate is a public document: anyone who has seen the connection can copy it, so presenting one proves only that such a certificate exists and chains to a trusted root. What it does not prove is that the sender is its subject. CertificateVerify supplies exactly that missing half by signing this specific conversation with the private key the certificate names — a key that is never transmitted, and a signature that cannot be replayed from an earlier session because the transcript is different every time. Presenting an identity and proving possession of it are two messages doing two jobs, and the set is built so that collapsing them is not possible. Finished then closes the one remaining gap. The earliest messages were sent before any key existed, so nothing protected them in flight; the keyed transcript hash is what retroactively guarantees they were not altered, and it is the specific mechanism that defeats a downgrade attack in which an attacker strips strong cipher suites from the client's offer. The last card leaves the handshake behind on purpose, because the handshake is not the protocol. Once the session keys are installed, the record protocol carries the traffic under symmetric AEAD encryption, and none of the handshake structures move a byte of payload — which is the division of labour fscr-04's own lessons draw between the TLS Record Protocol and the TLS Handshake Protocol. Seven cards are shipped rather than the six the ticket listed, and the extra one is EncryptedExtensions. The module's own lesson, TLS Handshake Protocol (fscr-04-0040), teaches TLS 1.3 as three phases — key exchange, server parameters, authentication — and without EncryptedExtensions the server parameters phase has no card at all, since RFC 8446 is precisely where that phase lives once cipher-suite selection moved into ServerHello. Shipping the ticket's six would have built something technically correct that floats free of the lesson the student just watched. All seven cards are presented on every run rather than sampled: this is the naturally finite domain the pool guideline makes an exception for — a handshake with a message removed is not a shorter version of the same object, it is a broken dependency chain, and the chain is the entire skill being assessed. This pairs best with the module's own sequence — run it after TLS Handshake Protocol and alongside Cipher Suites, so that the suite the second card selects is a thing the student can already read.
About TechKnowSurge
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →