Comprehensive review — finish with cases
Eight cases modeled on real situations, cutting across all six chapters. When stuck, return to the matching chapter for a quick review.
Eight finishing problems — bring the three questions
The final chapter is pure exercise. Eight cases modeled on real situations, spanning all six chapters. Whenever you hesitate, return to the course motto — what is missing right now: the peer check, the secrecy, or the tamper detection?
| If stuck on… | Review |
|---|---|
| The padlock's coverage; the three guarantees | Chapter 1 |
| The four tools; key directions | Chapter 2 |
| Hand-computing mod; forward secrecy | Chapter 3 |
| Certificate chains; the three checks; private-key handling | Chapter 4 |
| Handshake flow; SNI; 0-RTT | Chapter 5 |
| Reading openssl; error triage | Chapter 6 |
Case 7-1 — What is protected, and what is not
Chapters 1–3 territory. Return to the three questions.
Q1. Case: a user says, "The site had a padlock, but it was fake — and I typed in my card number." What is the correct explanation?
Chapter 1's line. Attackers legitimately obtain certificates for their own domains (say, examp1e-support.com) and display padlocks. A genuine padlock on a fake domain protects nothing. This is why checking the domain name in the address bar is the user-side keystone.
Q2. Case: reviewing the course, you pick secret a = 4 in Diffie–Hellman with p = 23, g = 5. What public value A = 54 mod 23 do you send?
5² = 25 ≡ 2, and 5⁴ = (5²)² ≡ 2² = 4. The answer is 4 (dividing directly also works: 625 = 23 × 27 + 4). With Chapter 3's pattern — square repeatedly, reduce every step — this is a ten-second calculation.
Q3. Case: an attacker recorded a full year of a server's HTTPS traffic. Later, the server's long-term private key (the certificate's key) leaked. What happens to the past TLS 1.3 traffic?
Forward secrecy (Chapter 3), exactly. In TLS 1.3 the long-term key's job is signing (stopping impersonation), not seeding session keys. The leak does require revocation and re-issuance to prevent future impersonation — but the recorded past stays protected.
Case 7-2 — Separate errors from attacks
Chapters 4–6 territory. Use the translation into 'which of the three checks failed.'
Q4. Case: reproducing a man-in-the-middle in a test lab, the attacker's device presents a self-signed certificate. What does the browser do?
A self-signed certificate connects to no CA in the root store; the signature-chain check fails and the warning appears. This is Chapter 4's design paying off: the MITM is defeated not by 'unbreakable encryption' but by being exposed at certificate verification. It also explains exactly what 'proceed anyway' would mean.
Q5. Case: on a link with RTT 80 ms you migrate from TLS 1.2 (2-round-trip handshake) to TLS 1.3 (1 round trip). After TCP setup, by how many milliseconds does time-to-first-encrypted-data shrink?
2 × 80 = 160 ms becomes 1 × 80 = 80 ms — an 80 ms saving, on every connection. For connection-heavy mobile apps and APIs it is tangible. Session resumption (PSK) and 0-RTT shave more, with 0-RTT carrying the replay caveat (Chapter 5).
Q6. Case: a new API client pointed at production fails certificate verification; the same URL works in a browser. Looking at the server's response in openssl s_client, which hypothesis do you check first?
"Browser works, everything else fails" is the classic missing intermediate (Chapter 6). Expiry would fail in the browser too. If s_client's Certificate chain shows only the leaf, it's confirmed — and the fix is configuring the intermediate on the server, not disabling verification client-side.
Case 7-3 — Operational judgment
Finally, decisions as an operator. The structure 'what is secret, what is public' yields the answers.
Q7. Case: a server misconfiguration briefly exposed the TLS private-key file to external download. What is the appropriate response?
An attacker holding the private key can impersonate the domain (forging the CertificateVerify signature). Waiting for expiry means permitting impersonation until then. Revocation (Chapter 4) plus re-issuance with a new key pair is correct — grounded in Chapter 4's line: certificate public, private key guarded.
Q8. Case: an internal system's certificate expired, and users report "the error page doesn't even show an 'Advanced → proceed' button." What is the cause?
On an HSTS site (Chapter 6), the browser enforces HTTPS and offers no 'proceed anyway.' Nothing is broken; a safety device the site itself requested is engaging. Recovery is renewing the certificate, not hunting for bypasses — and this is precisely why days-to-expiry monitoring exists.
Closing — carry the three questions with you
Well done. This course asked you to memorize almost no algorithm internals. What it asks you to carry instead are three questions that work everywhere:
- Is the peer genuine? — Does the chain reach the root store? Does the name match? Was private-key possession proven?
- Is the content secret? — Was a key agreed? Is there forward secrecy? What, like SNI, remains visible anyway?
- Has it been tampered with? — AEAD's integrity protection; Finished checking the whole handshake
At a certificate-error screen or in a security design review, walking these three in order narrows down cause and remedy. Don't silence the error — find which question is answering "no." That is the reading skill this course set out to build.