Worksheet: TLS Handshake

Fix / Extend

1. Fix. A client is being written that validates the certificate chain and then treats "the chain validated" as "this handshake is safe". Using your Reuse the server's certificate column, say what that client would accept and what the attacker would be holding, and name the check it left out.
2. Fix. A second client checks the chain and the CertificateVerify signature but skips both Finished MACs. Using your second table, say which of the two faults it would still refuse and which it would accept, and describe what the two ends would be left holding in the case it accepts.
3. Extend. In section 5, open Show one derivation in full — how server_handshake_traffic_secret is computed. Record the parent secret it takes, the label it uses, and what its context value is a hash of. Say which of those three would read the same on a classmate's screen and which would not, and why.
4. Extend. Section 8, Scope — What This Demo Does and Does Not Model, states that the application-data record is the one that is actually AEAD-sealed here, and that messages badged with a handshake key are framed and computed for real but not separately encrypted. Using the badge column of your first table, say which rows that statement applies to, and what the badge is describing if it is not an encryption step this page performed.
5. Extend. Section 8 also states that chain validation here is three things: the root matches the trust anchor, the root self-signature verifies, and the leaf is signed by the root. Those are the first three of the four verdicts in your second table's section 4 row. List three checks the panel says a real client performs that are absent from this model, and say what a reader of your tables should therefore not conclude from those three verdicts passing.
6. Extend. Your second table records section 4's chain verdicts for the honest session only; take them back under each fault. In Break this handshake, press Honest session and read the four verdicts in section 4, Authentication — Certificates & Signatures — root matches trust anchor, root self-signature valid, leaf signed by root, CertificateVerify signature valid. Press Break the ECDHE agreement and read all four again, then Flip a byte in flight and read them a third time. Write down which verdicts changed under each fault and which did not, then say what the unchanged ones are computed over that neither injection touched, and which of the two faults reaches the signature check at all.
7. Extend. Two of the three attacker moves in section 4 are refused, and by different checks. Press Reuse the server's certificate, then Sign with its own key, and for each read the five checks in the result box together with the certificate line above them, which says whether the presented leaf is the genuine server leaf. Name the check that stopped each move, say what each of those checks binds the session to, and use that certificate line to explain why the two moves fail in different places.
8. Extend. With Honest session selected in Break this handshake, and before pressing anything else, write down the first four hex characters of five values: the leaf Ed25519 public key in section 4, the Early Secret and the Handshake Secret in section 5, the client-computed shared secret in section 3, and the ciphertext and GCM tag in section 6. Then press New session, which re-runs the handshake with fresh keys and returns the walkthrough to the first step, and read the same five again. Mark which of them changed. Two read the same afterwards, for two different reasons: give both, using what section 5 says about the Early Secret and what section 4 says about the leaf key.