"What is TLS?" has had four completely different answers across 30 years. SSL 1.0 era: "RC4 + RSA." SSL 3.0 / TLS 1.0 era: "a handshake plus a record layer." TLS 1.2 era: "a configurable list of cipher suites." TLS 1.3 era: "an authenticated key exchange plus an AEAD record layer, and we're not letting you pick anymore."

Each rewrite was driven by a new class of attack. RSA export controls + RC4 bias; CBC and padding oracles; BEAST/CRIME/Lucky13 turning configurability into attack surface; and finally, in 1.3, the decision to cut every unsafe option. This chapter sets up three formulas that pin down TLS's skeleton — every subsequent chapter will refer back to them.

These three are orthogonal in TLS. Swap the AKE (X25519 → ML-KEM) and the record layer doesn't care; swap the AEAD (AES-GCM → ChaCha20) and the AKE doesn't care; remove tickets and you fall back to 1-RTT but the handshake itself is untouched. That orthogonality is TLS 1.3's biggest design win — when post-quantum KEM landed in 2024, only one field (key_share) changed.

TLS 1.2 needs 2 RTTs before the first HTTP byte (TCP 1 RTT + TLS 2 RTTs). TLS 1.3 compresses this to 1 RTT with one simple move: the client stuffs the key_share into ClientHello upfront, so the server can derive the shared secret on first sight. TLS 1.2 hides key_share inside the second-flight ServerKeyExchange, mandating an extra round-trip. This sounds like a small change but it required rewriting the entire handshake state machine — RFC 8446 took 4 years and 28 drafts to land.

All three were optional in TLS 1.2 — an admin could disable ECDHE and use RSA-KEX, accept SSLv3 fallback, use SHA-1 transcripts. Each off-switch maps to a CVE: FREAK, Logjam, POODLE, SLOTH. TLS 1.3's answer: delete the options. RSA-KEX deleted. CBC deleted. Renegotiation deleted. Compression deleted. SHA-1 deleted. "Can't turn it off even if you want to" is the security guarantee of 1.3.

SSL 1.0 lived three months in Netscape's 1994 conference room — internal review caught "RC4 stream key without a nonce" and it never shipped. SSL 2.0 lasted a year before the 1995 cipher-suite rollback attack killed it. SSL 3.0 lasted three years, vulnerable from 1998, finally killed by POODLE in 2014. TLS 1.0/1.1 lasted 18 years, survived BEAST, formally deprecated by IETF in 2020. TLS 1.2 has lived 10 years (2008–2018) and still serves >60% of internet connections. TLS 1.3 (2018–?) is replacing it.

This isn't technology history — it's the history of attacks driving iteration. Every major version bump maps to a CVE. The table below aligns them.

TLS 1.2 defined 28 cipher suites in RFC 5246, growing to ~340 combos via extensions (EXPORT, 3DES, CBC, RC4 — historical baggage). TLS 1.3 in RFC 8446 §B.4 cut the catalogue to 5, all AEAD:

The naming changed too. TLS 1.2 names like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 chain five independently-negotiated fields — five attack surfaces. TLS 1.3 names only carry AEAD + hash; signature algorithm and key-exchange curve are negotiated in separate extensions. "Composability is attack surface" is a core design observation of 1.3.

"Why not incrementally patch TLS 1.2?" was the TLS WG's most-debated question in 2014. The answer: 1.2's handshake has four structural deadlocks, each of which needs a backwards-incompatible break to fix. If you're breaking compat anyway, just rewrite.

TLS 1.2's handshake mandates ClientHello → ServerHello (RTT 1) to swap cipher suite and random, then ServerKeyExchange / ClientKeyExchange (RTT 2) to swap DH public keys. To squeeze this to 1 RTT the client must guess a curve upfront. 1.2 doesn't support guessing — its ClientHello carries a cipher-suite list, no key share.

RSA key exchange (RFC 5246 §7.4.7.1) has the client encrypt a pre-master secret with the server's public key. If five years later the server's private key leaks, an attacker holding 5-year-old pcaps can decrypt every historical session. That's no forward secrecy. Only after the 2014 Snowden documents — "NSA harvests HTTPS pcaps waiting for key leaks" — did the industry universally catch on. TLS 1.3 simply deleted RSA-KEX, leaving only ECDHE (ephemeral keys per session).

TLS 1.2 lets you "renegotiate" mid-connection — switch cipher, request a client cert, rekey. CVE-2009-3555 showed: an MITM can prepend arbitrary handshake bytes so the client thinks "just connected" while the server thinks "renegotiating," and the attacker's bytes get parsed as a GET parameter — letting attackers inject cookies into HTTPS POSTs. The fix (RFC 5746 "renegotiation indication") had both sides remember the previous Finished MAC — complex, slow to adopt. 1.3's fix: delete renegotiation. Need to rekey? Use the new KEY_UPDATE message — not a handshake, just a record-layer rekey.

TLS 1.2 has the client send a cipher-suite list, server picks one, but ClientHello itself isn't encrypted. FREAK and Logjam used the same trick: an MITM rewrites the ClientHello to advertise only EXPORT ciphers (512-bit DH, breakable in hours), the server thinks the client can't do strong crypto, downgrades. MAC can't catch this — MAC is over the transcript but there's no key yet at this point in the handshake.

1.3's downgrade sentinel breaks the cycle: the server embeds "DOWNGRD\01" in the last 8 bytes of ServerHello.random if the client originally supported 1.3 but got downgraded. Since Finished MAC covers ServerHello.random, the MITM can't downgrade unseen.

Three of the four require breaking ClientHello, the cipher-suite catalogue, or the handshake state machine. If you're breaking anyway, break cleanly — that's why TLS 1.3 isn't called "TLS 1.2.1".

From here on, every byte-level discussion in this book traces back to this one concrete handshake. The client is curl 8.6 (linked against OpenSSL 3.2) targeting https://ursb.me/. The server is nginx 1.27 on my Aliyun box, with a Let's Encrypt ECDSA-P256 cert (chain length 2), X25519MLKEM768 hybrid post-quantum KEM enabled, and ECH (using cloudflare-ech.com as outer SNI).

The 10 phases at a glance:

Each phase gets a byte-level expansion in the corresponding later chapter. The map below tells you where to look:

ClientHello is the only plaintext TLS message — everything afterwards is encrypted. In under 1 KB it has to tell the server: who I am, what protocol version I want, which key-exchange curves I support, my pre-generated public key for each (key_share), which AEAD cipher suites I accept, which signature algorithms, which hostname (SNI), which application protocol (ALPN), whether I want to resume a previous session (PSK), and whether I want to send application data immediately (early_data).

All of this lives in a single struct defined in RFC 8446 §4.1.2. Structure first, bytes second.

The skeleton is just four fields — the real TLS 1.3 protocol hides inside the extensions list. This is deliberate middlebox-compat design: 1.2-era middleboxes only inspect the top fields and pass through anything with legacy_version = 0x0303 (TLS 1.2). The "real version" lives in the supported_versions extension, telling 1.3-capable servers "I actually want 1.3".

In the main-line handshake, key_share takes 1216 bytes — 70% of the entire ClientHello. Reason: the client pre-generates a public key for each curve it supports. X25519 = 32 B, P-256 = 65 B — about 100 B total. But the ML-KEM part of X25519MLKEM768 is 1184 B by itself. Post-quantum bloats ClientHello from ~300 B to ~538 B — this was the single most-debated cost in 2024 PQ-KEM deployment. Ch21 has the deep dive.

The most painful discovery of TLS 1.3 design: the internet is full of middleboxes that "read TLS fields but reject unknown values". They were a non-trivial fraction of 2014 traffic — CDNs, enterprise proxies, home routers, IoT gateways, anti-DDoS appliances. Any one of them sees an "unfamiliar record_version" or "unknown cipher number" and slams a RST. 1.3's protocol was forced to "pretend to be 1.2", with five disguise fields, all mandatory:

The fifth is the most theatrical: dummy CCS is a pure ritual. TLS 1.3 has no ChangeCipherSpec (key changes are driven by the HKDF tree, no separate notification needed), but not sending one makes middleboxes think "client didn't enter key-exchange phase" and RST. So RFC 8446 mandates both sides send one empty CCS — purely for middleboxes to see. The receiver immediately drops it; it never enters the state machine.

Middlebox compat handles "how does a deployed protocol survive", but leaves a second-order problem: any new cipher suite / extension number could collide with "unknown value → RST" middleboxes. How to train middleboxes to accept the unknown?

Google's 2016 answer: GREASE (Generate Random Extensions And Sustain Extensibility, RFC 8701). The client deliberately stuffs reserved "fake" values into ClientHello — reserved cipher suite IDs (0x0A0A, 0x1A1A, …, 0xFAFA), reserved extension types (0x0A0A, 0x2A2A, …), reserved curve group IDs.

The logic: the server sees these and knows they're fake (the spec literally says "ignore"). But a middlebox sees them as real unknown values. If the middlebox RSTs because of them, someone catches it immediately and reports the vendor. "Send some 'unknown' deliberately so middleboxes adapt" trains the ecosystem to be lenient — so when the next genuinely new thing arrives, middleboxes don't kill it.

Chrome has sent GREASE in every ClientHello since 2016. Firefox / Safari followed. BoringSSL is the reference implementation.

The main-line handshake has ECH on, so two ClientHellos actually traverse the wire:

• Outer ClientHello — SNI says cloudflare-ech.com, the public "envelope". Middleboxes only see this one.
• Inner ClientHello — SNI says ursb.me, HPKE-encrypted and stuffed into the encrypted_client_hello extension. Only Cloudflare's ECH frontend can decrypt.

The two must look identical in size, field order, extension order — otherwise traffic analysis distinguishes ECH-enabled from not. Ch19 covers the details.

ServerHello looks symmetric to ClientHello — same random + cipher_suite + extensions — but it's a third the size. Reason: the client sends a list ("I support A, B, C"); the server sends a choice ("I pick B").

The server returns three things only: which cipher suite, which supported_group, and its own key_share public key. Every other extension moved to EncryptedExtensions (next chapter). This is one of 1.3's quiet revolutions: only extensions that affect key derivation may appear in plaintext ServerHello.

HRR looks identical to ServerHello — even the message type is ServerHello(2). The only difference is the random field, which is a fixed sentinel:

The client sees this random and knows: "Not a real ServerHello — the server is asking me to redo ClientHello." Two reasons:

1. Group mismatch — none of the client's key_shares match a curve the server accepts, but supported_groups does include one. The server writes selected_group in HRR; the client generates a fresh key_share for that curve and resends.
2. Cookie needed — server uses DDoS defence to require a cookie in the second CH (anti-reflection, similar to QUIC's Retry).

HRR stretches the handshake from 1 RTT to 2 RTT — but most clients default to sending X25519 + P-256 key_shares, hit rate is very high, and real HRR happens in <0.1% of connections.

In TLS 1.2 the entire ServerHello + extensions + Certificate + signature ride in plaintext. An MITM reads which site you're visiting, which ALPN, which client cert was requested. TLS 1.3 moves all of this into EncryptedExtensions / Certificate / CertificateVerify, protected by handshake_traffic_secret. From the moment ServerHello finishes, the rest of TLS is encrypted — only ClientHello stays plaintext (which is why Ch19 ECH then wraps even that).

EncryptedExtensions is the first message in this encrypted band, carrying extensions that are "needed during handshake but irrelevant to key derivation."

EncryptedExtensions deliberately doesn't carry Certificate — Certificate is its own handshake message (type=11). Message-boundary reason: certs can be large (chain-of-3 + OCSP staple = 8 KB), so giving it its own message lets the record layer handle fragmentation cleanly. Also matters for the PSK path: pure PSK resumption skips Certificate entirely; the state machine then jumps directly from EE to Finished.

In TLS 1.2, every server extension (SNI ACK, ALPN, status_request, heartbeat, …) sat in plaintext ServerHello. The MITM saw everything. TLS 1.3 splits them into three classes, routed by "does this affect key derivation":

The rule: "need it for key derivation → SH; not needed → EE". SH's three plaintext extensions are the necessary evil; EE swallowed everything else the MITM had no business seeing. Ch18 SNI shame + Ch19 ECH exist to also seal those last three plaintext fields.

By this point both sides hold two secrets: the (EC)DHE shared secret (derived from key_share — 32 bytes for X25519, 32+32=64 for hybrid PQ) and — on resumption — a PSK (from the prior NewSessionTicket). On the first visit to ursb.me, only the former. But TLS 1.3 doesn't feed these directly into AEAD. It runs a key derivation pipeline that expands the root seed into 8 keys for distinct purposes.

The expander is HKDF (HMAC-based Key Derivation Function), RFC 5869. Its core idea: Extract condenses weak entropy into a uniform PRK; Expand grows PRK into arbitrary-length output. TLS 1.3 adds a Derive-Secret wrapper that binds the transcript-hash into every key derivation — guaranteeing keys can never cross handshakes.

HKDF-Expand's info field isn't arbitrary in TLS 1.3 — RFC 8446 §7.1 requires it to encode as the HkdfLabel struct. The "tls13 " prefix is a cross-protocol domain separator: keys derived for TLS can't be accidentally interpreted by another protocol's HKDF (e.g. QUIC before RFC 9001 wired it in).

Walk through one with real bytes from the main-line ursb.me handshake: derive client_handshake_traffic_secret. Inputs: handshake_secret + literal label "c hs traffic" + transcript_hash(ClientHello ‖ ServerHello). The hex below is from an actual capture — paste it into any HKDF library and the output should match.

Each traffic_secret further derives a pair: key ("key" label, 32 B for AES-256) + iv ("iv" label, 12 B) — 6 AEAD contexts × 12 B = 72 B of IV storage. exporter_master_secret is TLS's "back door" to the application layer — apps call SSL_export_keying_material(ssl, label, context, length) and get any HKDF-Expand-Label-derived secret. QUIC uses it to derive Header Protection keys (RFC 9001 §5.4); OAuth Token Binding derives binding keys from it (RFC 8473).

Four reasons TLS needs an HKDF tree, not "one HMAC + truncate":

1. Key isolation — handshake keys ≠ application keys; client→server ≠ server→client. Each pair is independent; leaking one doesn't compromise others.
2. Rekeying — application keys can rotate via KEY_UPDATE (Ch11) without a new handshake. Requires master_secret to be a long-lived expand-able root.
3. Transcript binding — Derive-Secret's third arg is the transcript-hash. Change one byte of handshake content → derive completely different keys → AEAD decryption fails → MITM tamper is detected immediately.
4. 0-RTT early availability — early_secret derives the instant ClientHello is written (PSK-only); so does client_early_traffic_secret. All 0-RTT magic flows from here.

By this point the client knows two unconnected facts: (a) I read a public key out of an X.509 cert chain (claimed to belong to ursb.me), (b) I negotiated an ECDHE shared secret with this server. But these two haven't been tied together — the cert could have been replayed by an MITM (real pubkey, but the privkey is elsewhere), and ECDHE can be done by anyone. The MITM needs to simultaneously hold the private key and be the ECDHE endpoint to fully impersonate ursb.me.

CertificateVerify ties the two together: the server signs a fixed structure that includes the transcript-hash with the private key matching the cert. The client verifies: if it passes, the handshake peer (1) holds the private key (identity) and (2) saw the full handshake from ClientHello through Certificate (consistency).

The "64 spaces + label" looks weird but defends against cross-protocol confusion: if the server reuses the same private key elsewhere (say, SSH) to sign some data, the leading 64 spaces guarantee that data can't be "cast" as a TLS CertificateVerify. RFC 8446 borrowed this idea from Apple's codesigning design.

ECDSA-P256 is the main-line signature algorithm. It operates on the prime256v1 elliptic curve; the private key d is a 32-byte random integer; the public key is Q = d·G (G is the base point). To sign a message m:

Verification mirrors it: w = s⁻¹ mod n, u₁ = z·w mod n, u₂ = r·w mod n, compute (x', y') = u₁·G + u₂·Q, check x' mod n == r. The security rests on ECDLP — given Q = d·G, recovering d takes 2^128 classical operations.

Common confusion: the cert has a pubkey, why not just use it for ECDHE? Two reasons: (1) cert pubkeys are typed — RFC 5280 KeyUsage may mark a cert as sig-only. (2) Forward secrecy — cert private keys are long-lived (90 days, a year); a leak is catastrophic. ECDHE generates a fresh keypair per handshake (one-time pad), so even if the cert privkey leaks ten years later, past pcaps stay unreadable. That's why 1.3 mandates ECDHE; 1.2-era RSA-KEX had no such protection.

CertificateVerify proves the server holds the private key. But the handshake faces another risk: downgrade or tampering — an MITM rewrites supported_groups in ClientHello to force a weak curve, rewrites cipher_suite in ServerHello, adds/removes extensions in EE. If the tamper happens to a field that predates encryption, it doesn't break later AEAD (the keys are bound to the transcript, ciphertext won't decrypt — but the attacker can make both parties agree on the tampered transcript).

Finished is the last handshake message each side sends — it's the HMAC of the transcript-hash, keyed by finished_key. Both sides independently verify the peer's Finished. If the transcript they computed differs from the transcript I computed by even one byte, the HMAC won't match and the handshake aborts.

Note finished_key is direction-specific: client_finished_key derives from client_handshake_traffic_secret, server's from server_handshake_traffic_secret. This guarantees the client's Finished can never be reflected back as the server's.

A common misconception: "computing Finished requires retaining every handshake message byte from ClientHello onward." Not so — SHA-384 is a streaming hash; messages can be fed into the hash context as they arrive, without retaining the raw bytes.

RFC 8446 §4.4.1 enumerates every "snapshot moment" — six transcript_hash snapshots in total (CH / CH+SH / CH+...+EE+Cert+CV / +ServerFinished / +ClientFinished / +EndOfEarlyData for 0-RTT). Each snapshot is a copy of the hash_ctx state, then finalize; the original ctx keeps consuming messages. SHA-384's internal state is 200 bytes — 200 bytes total no matter how big the handshake. This is one of the main reasons TLS 1.3 servers use less memory than 1.2; 1.2 had to retain the whole transcript until Finished to compute the PRF.

The 1-RTT magic happens here: once the client verifies the server's Finished, the application_traffic_secrets are derivable (the HKDF tree has the inputs). The client immediately encrypts GET / with client_application_traffic_secret_0 and ships it in the same record flight as the client Finished. The server processes Finished first, then decrypts the trailing application record — but only if the MAC verifies. Handshake + first HTTP request byte in one RTT.

Post-handshake, every HTTP byte rides inside a TLS Record. Records are TLS's only transport unit, both directions. In 1.3 there's only one record kind: AEAD-encrypted ApplicationData. Handshake / Alert / ChangeCipherSpec messages exist only as inner payload; the outer type is always 23.

A TLS 1.3 connection actually has three independent AEAD key + nonce spaces over its lifetime, each counting sequence_number from 0:

The key invariant: switching secret = seq_num resets + static IV re-derives. This is why P0-5's Python decrypt script specifically calls out "if it's wrong, the #1 cause is seq_num not being reset". Inspecting a pcap of one connection, every outer record type is 23 (ApplicationData), but internally the same connection traverses 4-5 key phases — only the KEY_UPDATE message signals the recipient that keys have rotated.

The key design move: "the nonce isn't on the wire". TLS 1.2 sent an explicit 8-byte nonce per record — wasted bandwidth + manipulable. 1.3 has both sides derive a static 12-byte IV from traffic_secret, then XOR a locally-tracked 64-bit sequence number. Both sides stay synchronised through successful decryption alone; lose one record and you desync.

This is why TLS 1.3 over TCP is order-sensitive: TCP guarantees byte order, sequence_number stays implicit. TLS 1.3 over QUIC (RFC 9001) can't do this — QUIC packets arrive out of order, so each packet must carry its packet number explicitly as the nonce input.

AEAD = Authenticated Encryption with Associated Data. AES-GCM is TLS 1.3's default AEAD (~90% of traffic). Internally it runs two parallel lines: (1) CTR mode turns AES block encryption into stream encryption; (2) GHASH does a universal hash over GF(2¹²⁸) to authenticate AAD + ciphertext. The tag is AES of GHASH output.

Key observation: the GHASH subkey H = AES_K(0^128) — every record under the same key shares the same H. That's why nonce reuse in GCM is catastrophic: two records with the same (K, nonce) let an attacker take two (C, T) pairs, solve the GHASH equation, and recover H; they can then forge tags on arbitrary records, fully bypassing AEAD's auth. TLS 1.3's seq-num XOR static-IV nonce derivation structurally guarantees nonce uniqueness. In 1.2 GCM, the explicit 8-byte nonce was implementation-chosen; "counter + random" implementations have hit nonce collisions in production (Cisco IOS 2016, NSS 2017).

Decryption runs the inverse: compute Y from GHASH(AAD ‖ ct ‖ lens), compare against tag XOR E_K(J0); mismatch → drop immediately (no partial decryption allowed). This is why AEAD is fundamentally safer than "MAC-then-Encrypt" — an attacker can't time the "ciphertext already partly decrypted" path as an oracle.

A long-lived TLS 1.3 connection (gRPC long-lived stream, WebSocket, idle IoT) can push enough bytes through a single traffic_secret to approach AES-GCM's security ceiling (~64 GB). 1.3 forbids renegotiation (Ch03 Sin 3), but offers KEY_UPDATE:

Notice the "_N+1" — traffic secrets are chained forward; old ones are immediately discarded. This gives rolling forward secrecy: keys rotate every N GB, so an attacker capturing the current key still can't decrypt traffic from N GB ago.

After the client Finished the handshake is done, but the server proactively sends one or more NewSessionTickets (NSTs) — vouchers for "save one RTT next time". The NST contains an opaque ticket (the server's own STEK-encrypted resumption_master_secret), a lifetime in seconds, and 0-RTT's max_early_data_size.

Edge CDNs like Cloudflare default to stateless — every edge node shares the STEK (Session Ticket Encryption Key), so a client can resume from any POP. Cost: the STEK is the entire CDN's single key and must rotate often. A leaked STEK breaks forward secrecy — an attacker decrypts every session from NST issuance to STEK rotation. A recurring theme in the Ch22 attack history.

The main-line handshake sees the server send two NewSessionTickets (Chrome accepts 2-5 by default). Reason: each ticket's PSK should be invalidated after one use (anti-replay — see Ch14), so concurrent requests with only one ticket left would fall back to 1-RTT. Chrome requests multiple at once per origin, so two concurrent tabs both get 0-RTT. RFC 8446 §4.6.1 explicitly allows "server SHOULD issue multiple tickets".

The client stores (ticket_blob, lifetime, resumption_master_secret) after the NST arrives. On the next visit to ursb.me:

1. Client puts a pre_shared_key extension in the new ClientHello (PSK identity = ticket_blob).
2. Client derives PSK from resumption_master_secret, runs the full Key Schedule (left PSK branch of the HKDF tree) to derive client_early_traffic_secret.
3. Client immediately encrypts GET / with client_early_traffic_secret and ships it alongside ClientHello. That's 0-RTT.
4. Server unwraps PSK, verifies the ticket isn't expired, accepts → 0-RTT confirmed → client sent data before the server's Finished even arrived.

The PSK identity (ticket) travels plaintext on the wire — any MITM can copy it. To prevent "I grab your ticket and impersonate you", 1.3 adds PSK binder: the client derives binder_key from PSK, then HMAC's the ClientHello (minus the binders field itself) with binder_key.

The key insight: binder is different every handshake, because binder = HMAC(binder_key, ClientHello[:binders_offset]) and ClientHello.random is fresh. An MITM can copy the ticket but can't recompute binder for a new ClientHello — they don't have binder_key, which derives from PSK from resumption_master_secret, which they don't have.

"HMAC over CH minus binders" literally means: take the bytes of the ClientHello the client just built, truncate at the byte offset where binders begins, HMAC the prefix. The prefix length naturally depends on every preceding field's byte count — so the server, on verification, must count from byte 0 of ClientHello to the start of binders.

The key invariant: binder HMAC's input = ClientHello bytes from offset 0 up to (but excluding) the binders length prefix. RFC 8446 §4.2.11.2 calls this slice PartialClientHello. Any MITM trying to "reuse ticket but tamper with other ClientHello fields" alters the prefix → HMAC fails → server rejects PSK and falls back to a fresh 1-RTT handshake.

psk_ke is IoT-only: a sensor has no privacy stakes after compromise. Web browsers always use psk_dhe_ke — every resumption still does fresh ECDHE, preserving per-session forward secrecy.

The temptation of 0-RTT: client sends app data before the server replies, slashing TTFB by 1 RTT for repeat visitors. But the fundamental flaw of 0-RTT is no freshness — the 0-RTT data is encrypted under client_early_traffic_secret, which derives from PSK + transcript that the client knew unilaterally. An attacker who captures that packet can replay it arbitrarily often; the server can't distinguish "you" from "recording".

For idempotent GETs, fine — querying twice yields the same result. But POST /transfer/100USD? A replay = 100 transfers. 1.3 has three defence layers; any two can fail and the third saves you.

client_early_traffic_secret in the HKDF tree only depends on PSK (before ECDHE input is injected). So:

• If PSK leaks → all 0-RTT data is decryptable.
• If STEK leaks (stateless tickets) → attacker decrypts the ticket, gets resumption_master, derives PSK, decrypts 0-RTT data.

1-RTT data doesn't have this problem — its derivation includes ECDHE, ephemeral per handshake. "0-RTT trades one layer of forward secrecy for performance" — repeated explicitly in RFC 8446 §E.5.

X.509 is PKIX's core data structure, defined by ITU-T in 1988, currently at v3 (RFC 5280). Internally it's described in ASN.1 (Abstract Syntax Notation One) and encoded in DER (Distinguished Encoding Rules) — a TLV binary format.

Intuitively, a cert is signed metadata. The metadata says "this public key belongs to CN=ursb.me, valid 2026-04-01 to 2026-06-30." The signature is the CA's stamp made with its private key. The client's job: find the CA's public key (in the root store), verify the signature, then trust the statement.

DER's rule is dead simple: every value encodes as Tag · Length · Value. Tag is one byte (type marker), Length is one-plus bytes (variable), Value is the actual bytes. SEQUENCE = tag 0x30, OCTET STRING = 0x04, UTF8String = 0x0c, INTEGER = 0x02, OID = 0x06, etc.

openssl x509 -text shows the decoded human view. To really understand what the cert looks like on the wire, read the DER bytes directly. Below: the first 64 bytes of ursb.me's leaf cert, annotated with each ASN.1 tag + length encoding form.

The pattern:

• Tag byte: top 2 bits = class (00=universal, 10=context-specific); bit 5 = constructed flag; low 5 bits = tag number. 30 = constructed universal SEQUENCE. a0 = constructed context-specific [0]. 02 = INTEGER. 04 = OCTET STRING. 06 = OID.
• Length encoding: < 128 → single byte direct; ≥ 128 → long form — first byte is 0x80 | num_bytes, followed by num_bytes big-endian length bytes. 82 04 12 = 0x0412 bytes (1042).
• OID encoding: first byte = 40·X + Y (X first arc, Y second); subsequent arcs base-128 with high-bit continuation. 1.2.840.10045.4.3.3: 40·1+2=2a, 840 = 86 48, etc.

12 lines walk the entire cert. The historical lesson of X.509 parsing bugs: openssl 1.0 had an integer overflow in long-form length parsing (CVE-2016-6303, affecting every ASN.1 decode path); Go's asn1 package in 2018 panicked on certain malformed OIDs (CVE-2018-16873). Every modern ASN.1 library uses BER/DER strict mode: reject indefinite length, reject any non-minimal encoding.

That CT Precertificate SCTs block in ursb.me's cert isn't decoration — here's the byte-level layout:

Chrome / Safari embed a "known CT logs" allow-list (~30 logs in Chrome 2026), updated periodically. A cert must carry SCTs from at least 2 independent allow-listed logs to be trusted. This shifts the "poll the log" responsibility from client to CA — CAs must submit a precert to the log and embed the returned SCT before issuing. The SCT is the unforgeable receipt of "this has been logged".

SCT delivery has three options: (a) X.509 v3 extension (most common, OID 1.3.6.1.4.1.11129.2.4.2); (b) TLS extension signed_certificate_timestamp (type 18, server sends fresh during handshake); (c) attached to OCSP response. Let's Encrypt uses (a); Cloudflare edges also send (b) with fresher SCTs.

Let's Encrypt sets all certs to 90 days. Reasons:

1. Damage cap — a leaked privkey is only useful for 90 days.
2. Forces automation — 90 days is too short for manual renewal; you must use ACME — dropping "I forgot to renew → outage" to near-zero.
3. Revocation window — Ch17 covers: OCSP propagation lag is worst-case 24 h; a short cert means a "forgot to revoke" attack window is also short.

In 2024 Apple proposed the "45-day cert" rule, ratified by CA/Browser Forum in 2025 — by 2027 all public TLS certs cap at 47 days, dropping to 47 by 2029. The short-cert movement continues.

The client verifies ursb.me's cert by looking up its issuer "Let's Encrypt E5" — that's an intermediate cert (also signed). It then looks up E5's issuer "ISRG Root X1" — and finds the root: ISRG Root X1 is self-signed, present in every browser/OS root store. The client doesn't verify root signatures (you can't verify a self-signature meaningfully); it simply pre-trusts the root.

Who decides which CAs end up in the root store? Four independent lists:

You can't buy your way in. Mozilla's CA inclusion process requires: full WebTrust audit, multi-year clean record, revocation responsiveness, CP/CPS docs, operational transparency. 1–3 years from application to inclusion. Eviction is fast — in 2017 Symantec was synchronously evicted by Google + Mozilla for serial misissuance, affecting 30% of internet certs. A CA seat rests on reputation + transparency + process all at once.

Chrome 105 (Sep 2022) switched to its own root store, no longer trusting the OS. Reason: Google didn't want "a nation-state forcing the OS vendor to add a root" or "OS vendor too slow to evict" to compromise Chrome users. This decentralises the trust anchor, at the cost of Chrome maintaining its own audit pipeline. In 2024 Chrome marked Entrust's root as "distrust after 2024-11-11" (Entrust had years of CT-compliance lapses) — another demonstration of this autonomy.

Typical chain length = 3: leaf (ursb.me) → intermediate (Let's Encrypt E5) → root (ISRG Root X1). Why intermediates? Three reasons:

1. HSM isolation — root private keys live in offline HSMs (typically airgapped, multiple-keyholder ceremonies). Intermediates do the day-to-day signing from online HSMs.
2. Internal architecture flex — if an intermediate is compromised (say Let's Encrypt R3 is RSA-broken), you rotate the intermediate without touching root.
3. Cross-signing — Let's Encrypt R3 was also cross-signed by IdenTrust's root, for compat with old Androids that don't have ISRG Root. The chain then becomes leaf → R3 → ISRG Root X1 OR leaf → R3 → IdenTrust DST Root X3, client picks whichever it trusts.

ursb.me's nginx config is wrong, the private key leaked. Let's Encrypt accepts a revocation request — but how does the client know? The cert is still syntactically valid within its 90-day window; reading the cert alone can't distinguish "revoked".

30 years and three solutions: CRL (1988) → OCSP (1999) → CT log (2012). Each fixed the previous one's problem, but all three still run.

1. Server periodically (default 1 h) queries its CA's OCSP responder for its own cert's status.
2. Receives a CA-signed OCSP response (timestamped), caches in memory.
3. During TLS handshake, server stuffs status_request into CertificateEntry extensions, stapling the OCSP response into the handshake.
4. Client verifies OCSP response signature (signed by the cert's issuer), checks ThisUpdate / NextUpdate timestamps, confirms not revoked. The client never talks to the CA — privacy and latency both win.

In 2011 DigiNotar was hacked, fake *.google.com certs got issued. Problem: Google didn't know. CT log fixes this — when a CA signs a cert it must simultaneously submit it to ≥ 2 (default 3) CT logs. Logs are append-only Merkle trees operated publicly by Cloudflare, Sectigo, Google. Anyone can audit — "I see a *.google.com cert issuance but Google didn't issue it; alert!". This watchdog model means a fake cert can't escape detection, even if it can be signed.

Concrete artefact: every cert carries 2-3 SCTs (Signed Certificate Timestamps). An SCT is a log's signed promise "I have seen this cert". Browsers (Chrome enforces) only accept certs with ≥ 2 independent-log SCTs. That's the source of the X509v3 CT Precertificate SCTs block in the ursb.me cert from Ch15.

TLS 1.3 almost achieved "reveal nothing except your existence" — version, cipher, extensions, cert, signature, app data, all encrypted. The lone exception: ClientHello.server_name (the SNI extension), which carries the target hostname in plaintext.

Why is SNI needed? A single IP hosts many HTTPS sites (Cloudflare runs 1M+ domains per IP). The server must know which hostname the client wants at ClientHello time, to pick the right cert. Encrypting SNI would be chicken-and-egg — the server can't decrypt without keys it hasn't derived yet.

So ClientHello carries SNI plaintext. The cost: anyone who can see IP packet headers — your ISP, café WiFi, nation-state DPI, enterprise proxies — sees every hostname you visit. That's the SNI shame.

In 2018 Cloudflare launched ESNI (Encrypted SNI): encrypt the ClientHello.server_name field with a public key from a DNS TXT record. Looked great but had serious flaws:

• Client needs an extra DNS lookup for the key, adding 1 RTT.
• ESNI only encrypts the SNI field — other extensions (ALPN list, sig_algos order) still leak fingerprints.
• Bit-probe attack: ESNI clients fallback to plaintext SNI on failure; an MITM can trigger fallback and read SNI in cleartext.

Iran simply blocked the ESNI extension itself in 2020 — its extension number 0xffce stood out clearly in ClientHello. That failure spawned ECH: encrypt the entire inner ClientHello, outer is a decoy.

ECH's core idea: client sends two ClientHellos. Outer ClientHello is public, with SNI = "which ECH frontend the client is on" (not the real destination). Inner ClientHello is the real one, with the real SNI, HPKE-encrypted and stuffed into outer's encrypted_client_hello extension.

HPKE (Hybrid Public Key Encryption, RFC 9180) is a unified interface for "encrypt a small payload to a public key" — fuses KEM + KDF + AEAD. ECH uses HPKE to seal the inner ClientHello in one chunk. Where does the public key come from? DNS HTTPS RR (RFC 9460) — a new DNS record type 65 carrying TLS metadata including ECHConfig.

The key design trick: kem_context feeds both public keys into the KDF, defending against "key compromise impersonation" — even if an attacker grabs sk_R, they can only decrypt one session, not forge others' enc values. HPKE is reused beyond ECH — by MLS, Oblivious DNS-over-HTTPS, Privacy Pass — as a unified asymmetric-encryption interface, so each protocol doesn't have to stitch KEM+KDF+AEAD itself.

ECH's privacy guarantee has a key fragility: if ECH-on and ECH-off ClientHellos differ in size, extension order, or padding pattern, DPI can still distinguish. So the RFC mandates:

• Outer and Inner ClientHellos must look the same size (pad via ECH padding extension).
• Outer's extension set must be a superset or equal of Inner's (extensions like ALPN reference the inner one via outer_extensions).
• Clients must not change ClientHello size distribution due to ECH support — otherwise that becomes the fingerprint.

RSA, Diffie-Hellman, ECDH all rest on the hardness of integer factoring or discrete logarithm. Classically these problems are sub-exponential — RSA-2048 takes ~3×10⁷ years even with superhuman resources. On a quantum computer? Shor's algorithm (1994) solves both in polynomial time.

Concrete numbers: breaking RSA-2048 takes about 2000 logical qubits + 3 billion gates (Gidney & Ekerå, 2019). Today's largest quantum machine (IBM Condor 2023) has 1121 physical qubits, but each logical qubit needs ~1000 physical qubits for error correction — so realistically 2M physical qubits are needed. We're roughly 1000× away.

Question: when? NIST's 2024 official guidance: "sensitive data must complete post-quantum migration by 2030". Not because 2030 has the quantum machine, but because of harvest now, decrypt later — intelligence agencies can record TLS today and decrypt in 2040 when quantum matures. Any data with 10-year confidentiality needs is already at risk.

Shor's algorithm isn't "brute-force every factor on a quantum computer". The core is reducing factoring to period-finding, then using quantum Fourier transform to find the period in polynomial time. Skeleton:

The key insight: step 2's "period r" must satisfy a^r ≡ 1 (mod N). In the multiplicative group ℤ/Nℤ, every element has finite order — that order is the period. Classical algorithms find this period in sub-exponential time (multiplying a, a², a³, … until back to 1); QFT lets a quantum machine superpose over all candidate r and collapse to the right one in a single measurement.

The same reduction solves discrete log (Diffie-Hellman's and ECDH's hardness base) — so Shor takes down RSA + DH + ECDH in one stroke. But symmetric crypto is outside Shor's reach: AES, SHA aren't period problems; Grover only gives a square-root speedup.

Note AES and SHA aren't fatally affected by Shor — Grover only gives symmetric crypto a square-root speedup. AES-256 retains 128-bit security; sufficient. The real danger is KEX and signatures, so TLS's PQ migration only touches key_share and signature_algorithms.

NIST calls "a quantum computer able to run Shor against RSA-2048" a CRQC. Academic median estimate for CRQC arrival: 2035–2040. Intelligence agencies (NSA, GCHQ) and quantum computing companies (IBM, Google Quantum, IonQ) project more aggressively — possibly early 2030s. That's why NIST issued the "all government-sensitive data" 2030 migration mandate in 2024. Apple iMessage's 2024 PQ switch, Signal's 2023 switch — chain reactions to this mandate.

Two ways to replace X25519 with PQ KEM:

1. Pure PQ — just ML-KEM, simple but risky. ML-KEM was only standardised in 2024 (FIPS 203); 1 year of real-world experience. A future fatal flaw means all TLS traffic gets decrypted pre-quantum-era.
2. Hybrid — run X25519 + ML-KEM together, concatenate both shared secrets as ECDHE input. Security = max(X25519, ML-KEM) — break one and the other still protects.

Chrome + Cloudflare in 2024 shipped hybrid: X25519MLKEM768 (IETF name). "768" is ML-KEM's security level — NIST level 3 (≈ AES-192), slightly above X25519.

ML-KEM's hardness comes from module-LWE (Module Learning With Errors). The LWE prototype: you're given (A, b), where A is an n × m matrix, b = A·s + e (mod q), s is a secret vector, e is small noise. Can you recover s from (A, b)? No sub-exponential algorithm exists, classically or quantumly — one of the few PQ-stable assumptions.

"module" in module-LWE means matrix entries are polynomials, not scalars — A ∈ R_q^{k×k}, where R_q = ℤ_q[X] / (X^n + 1). ML-KEM-768's concrete parameters: n=256, q=3329, k=3, noise η₁=2, η₂=2. These put ML-KEM-768 at AES-192 equivalent (NIST level 3).

ML-KEM's bottleneck is polynomial multiplication — multiplying two degree-256 polynomials in ℤ_q[X]/(X^256+1). Naive is O(n²) = 65536 multiplications. But ML-KEM's ring structure (X^256+1, q=3329) just happens to support the Number Theoretic Transform (NTT, the finite-field version of FFT), bringing polynomial multiplication down to O(n log n) ≈ 2048 ops.

Concretely: q = 3329 is chosen so that 256 ∣ (q-1), hence ℤ_q has a primitive 512th root of unity ζ = 17 (17^512 ≡ 1 mod 3329). NTT uses ζ to transform polynomials from "coefficient domain" to "point-value domain"; in the point-value domain multiplication is elementwise (O(n)); then transform back.

ML-KEM's public key (1184 B) and ciphertext (1088 B) are stored pre-transformed in NTT domain — saving 30-40% CPU by skipping repeated transforms during keygen/encap/decap. On AVX2 / AVX-512 / ARM NEON, one NTT layer is just a few SIMD instructions — the fundamental reason ML-KEM keygen is 1000× faster than RSA-2048 keygen.

NIST started the PQ competition in 2016, finalised Kyber (a module-LWE KEM) in 2022. FIPS 203 in 2024 renamed it ML-KEM (Module-Lattice-based Key Encapsulation Mechanism). Kyber is the community name, ML-KEM the NIST standard name — same algorithm, not entirely identical parameters. Production implementations track ML-KEM.

PQ-ifying KEM touches only client/server memory; cert chain stays the same. The real migration bottleneck is PQ certificates — CA root + intermediates need PQ-signed certs. Problems:

• ML-DSA-65 (NIST level 3, ECDSA-P256-equivalent security) signatures are 3309 bytes (vs ECDSA's 64). Certs balloon to ~8 KB.
• SLH-DSA (hash-based) signatures: 8000–30000 bytes, but no number-theory assumptions; the safest fallback.
• Chain-of-3 PQ certs = ~24 KB; handshake size multiplies severalfold.

So hybrid KEM is phase 1, cert PQ is phase 2; still in IETF draft. ETA 2027–2028.

This is the TLS security "kill list" — every attack killed some part of TLS. Reading backwards, this list explains exactly why TLS 1.3 had to delete so much.

April 7, 2014. Codenomicon and Google's Neel Mehta filed independent reports the same day: OpenSSL 1.0.1's Heartbeat extension was missing a bounds check. The extension (RFC 6520) lets a client send a "ping" record and have the server echo the payload — keep-alive. OpenSSL used the claimed payload length as the memcpy count, without verifying it matched the actual payload.

The attack payload is 4 bytes: 18 03 02 00 03 01 40 00 — record header (type=24 heartbeat) + length=3 + actual payload "01" + claimed payload_length=0x4000 (16384). OpenSSL sees length=0x4000 → memcpy's 16384 bytes back — but only 1 byte arrived. The remaining 16383 come from the same process's heap: someone else's plaintext request, private keys, cookies, passwords.

Damage: OpenSSL 1.0.1 ~ 1.0.1f, ~17% of HTTPS servers worldwide. Cloudflare reissued ~10k customer certs within a week; Yahoo / OkCupid / Imgur / Wikipedia ended up on the "keys leaked" list. RFC 8446 simply deleted Heartbeat from TLS 1.3 — features that don't exist can't be exploited. Heartbleed also triggered Google's decision to fork BoringSSL ("OpenSSL is too complex, we'll do it ourselves").

September 2011, ekoparty. Juliano Rizzo and Thiago Duong demoed a 90-second JavaScript attack: through the victim browser's concurrent HTTP requests over the same TLS 1.0 connection, they decrypted an HTTPS cookie.

The flaw lay in TLS 1.0 CBC's IV design: each record's IV = the last ciphertext block of the previous record. The attacker can therefore predict the next IV. With chosen plaintext, they can construct P = pre_chosen_block XOR IV_predicted XOR guess so the resulting ciphertext equals a target record's ciphertext block iff the guess is correct. One byte at a time, 256 tries per byte, the cookie peels off.

The "multiple records in one connection" prerequisite was supplied by JavaScript: cross-origin iframes firing fetches reused the TLS connection. RFC 5246 (TLS 1.1) had already fixed the IV — explicit per-record IV — but deployment lagged until ~2014. TLS 1.3 axed CBC outright; "chained IV" doesn't exist in 1.3's vocabulary.

May 2015, the weakdh.org paper: 8.4% of HTTPS top-million sites still supported DHE_EXPORT cipher suites (512-bit Diffie-Hellman group). A relic of US 1996 export-control rules — pre-1996, "military-grade" crypto couldn't leave the US, capping DH at 512 bits — was still alive in 2015.

Attack: MITM rewrites the client's cipher list to only DHE_EXPORT; server downgrades; both sides negotiate 512-bit DH. The 512-bit discrete-log problem, after group-specific number-field-sieve precomputation, falls in hours — and 80% of internet DHE_EXPORT implementations used the same hardcoded DH group (OpenSSL's default), meaning one precomputation breaks half the internet. Precomputation cost: ~$100M GPU-time over 2 weeks. The Snowden documents corroborated NSA actually doing this — a GCHQ slide referenced "decrypting trillions of keys".

TLS 1.3's three defences: (1) delete EXPORT cipher suites, (2) mandate ECDHE (replacing DHE; curve groups are publicly standardised), (3) downgrade sentinel + Finished MAC make any MITM downgrade detectable at the protocol layer.

Pre-1.2 versions were "design first, let academics break it" — every break is a CVE. TLS 1.3 inverted this: while the draft was still being written, researchers used formal-verification tools (Tamarin / ProVerif / F* / CryptoVerif) to prove "under the standard attacker model, no reachable security-failure state exists". This is the inflection point of TLS's 30-year history.

The recipe: translate RFC 8446 into a formal model (each message a process, each key derivation a rewrite rule), then let the tool auto-explore all reachable protocol states, looking for "secrecy lost" or "transcript disagreement" states. Tamarin actually found a real bug in 2017 — an early draft let an MITM make the two sides "accept" different transcript_hashes under a PSK + DHE combination. The bug was fixed before RFC 8446 final. First IETF protocol in history to be tool-proven before publication; MLS, Signal, QUIC all followed this template since.

In cryptography "less code = safer" is law — Heartbleed was a single missed bounds-check in ~500k lines of OpenSSL. rustls in ~25k lines has had zero memory-safety bugs to date. That's the core motivation behind Cloudflare swapping nginx for pingora (built on rustls).

Below is "build a TLS 1.3 client and send GET / to ursb.me" in three of the most common stacks. Same logic, same wire bytes, wildly different API mental models — the design-philosophy gap explains why swapping stacks is a multi-month migration.

OpenSSL's footgun: forget SSL_set1_host → cert signature verifies but hostname match doesn't; any valid cert lets an attacker MITM. Snyk's 2022 scan of 1M+ OpenSSL integrations on GitHub found ~8% of projects missing this one line. That's why rustls makes ServerName a mandatory constructor type parameter.

This single output is a cross-section of the entire article — every line maps to a chapter:

• 16 03 01 02 16 record header → type=Handshake · ver=TLS1.0 (middlebox compat) — Ch05
• Post-ServerHello dummy CCS (type=20, len=1, body=0x01) — Ch05 §middlebox compat five-piece
• Server Temp Key: ML-KEM-768, X25519MLKEM-768 — main-line PQ hybrid KEX from Ch21
• Cert chain shows 2 (leaf + LE E5), openssl lists 3 because it adds ISRG Root X1 — Ch16
• Secure Renegotiation IS NOT supported + Compression: NONE — Ch03 deadlocks, all matched

The end of all theory is "it runs". This snippet wires Ch08 (HKDF Key Schedule) + Ch10 (Finished) + Ch11 (AEAD Record) into a complete workflow — no Wireshark, just Python + cryptography, from one SSLKEYLOGFILE + one .pcap to the actual HTML bytes ursb.me returned.

This 80-line script does everything Wireshark's TLS dissector does — proving you truly understand TLS 1.3 record key derivation + AEAD + inner-type hiding. If it runs correctly, you can read the protocol byte-by-byte. The three most common bugs:

1. seq_num not reset to 0 (every KEY_UPDATE or traffic_secret change resets).
2. AAD set to the full record (should be just the 5-byte header).
3. HkdfLabel forgot the "tls13 " prefix on the label.

The ultimate goal of any tutorial: connect to a real server with your own code. Below, using rustls (Rust, ~25k SLOC, memory-safe), we build a minimal-but-working TLS 1.3 client — connect to ursb.me, send GET /, fetch the HTML. Fully runnable: cargo new tls-min && cd tls-min, paste the three blocks below, you're up. This is the capstone landing for all of Ch24's theory, mirroring HTTP/3 Ch25 "Hand-write 200 lines of quiche".

~70 lines total (Cargo.toml excluded). This is the entire boilerplate for a modern TLS client — rustls locks down "set root store / enable 0-RTT / set ALPN / verify hostname" (1.2-era footguns each) with types and defaults. The C + OpenSSL equivalent is 200+ lines and can still miss SSL_set1_host for a fatal bug (Ch23, Snyk's 8% finding). This is exactly why Cloudflare's pingora (rustls-based) replaced nginx + OpenSSL.

1. TLS 1.3 is a reckoning over unsafe options — RSA-KEX, CBC, renegotiation, compression, SHA-1, SSL: all deleted. "Composability is attack surface" is the core observation. (Ch01 · Ch03 · Ch22)
2. ClientHello is the only plaintext message — 538 bytes carry key_share / SNI / ALPN / sig_algos / supported_versions / PSK / early_data and ~10 extensions. Everything else is AEAD-encrypted. (Ch05 · Ch07)
3. 1-RTT's magic is ClientHello carrying key_share upfront — server derives keys on first sight; client Finished piggy-backs app data. (Ch01 · Ch10)
4. HKDF grows 8 keys from one root — each binds to transcript-hash; flip one byte → wrong keys → handshake aborts. (Ch08)
5. 0-RTT has no forward secrecy · GETs only — three defence layers (idempotent only / Early-Data header / TLS time-window + dedup); losing any one is catastrophic. (Ch13 · Ch14)
6. Cert subject is in SAN, not CN — CN is historical baggage; browsers ignore it. Let's Encrypt 90 days → 47 days post-2027. (Ch15)
7. CT log makes fake certs detectable — every cert must carry ≥ 2 independent-log SCTs. The biggest PKI improvement of the last decade. (Ch17)
8. SNI is still plaintext · ECH HPKE-wraps the whole ClientHello — outer/inner ClientHellos + DNS HTTPS RR public key delivery. draft-22, default-on at CF. (Ch18 · Ch19)
9. Post-quantum has started · X25519MLKEM768 is the default — hybrid design, security = max(X25519, ML-KEM). Cert PQ-ification is phase 2; ML-DSA signatures are 3.3 KB. (Ch20 · Ch21)
10. "Harvest now, decrypt later" is real — data with 10-year confidentiality needs PQ KEM today. NIST mandates 2030 migration. (Ch20)

This section archives every external spec, RFC, paper, or source-code reference the article touches. Each carries a status pill (STD = published RFC / PS = Proposed Standard / DRAFT = IETF Internet-Draft) + link + the chapter that uses it. All URLs valid as of May 2026; the TLS 1.3 + ECH + PQ ecosystem keeps moving — IETF tls / lamps / pq-crypto WGs publish drafts continuously.