<b>How does TLS 1.3 detect a downgrade attack using nothing but the server's random value?</b>

<b>How does TLS 1.3 detect a downgrade attack using nothing but the server's random value?</b>

Downgrade attacks force a connection to a weaker protocol the attacker can break — the lineage runs from FREAK to Logjam to POODLE. TLS 1.3 added a clever, low-cost defense that hides inside a field everyone overlooks: the ServerHello random.

The server's 32-byte random is supposed to be unpredictable. RFC 8446 §4.1.3 carves out the last 8 bytes as a sentinel. If a server that supports TLS 1.3 is negotiated down to TLS 1.2 (because an attacker tampered with the ClientHello to strip 1.3 support), the server sets those 8 bytes to a fixed value: the ASCII string "DOWNGRD\x01" for 1.2, or "DOWNGRD\x00" for 1.1 and below.

The trick is that the random is covered by the Finished MAC and, for 1.2, by the server's signature over the handshake transcript. A client that itself supports 1.3 but finds itself in a 1.2 handshake checks for the sentinel. If it sees "DOWNGRD", it knows a genuine 1.3-capable server is on the other end and the version was forced down by tampering — and it aborts. An attacker cannot forge the random without breaking the server's signature.

Evidence vs. speculation: this is a precise normative mechanism (RFC 8446 §4.1.3), not a heuristic. It only protects pairs where both endpoints support 1.3.

<b>Further reading:</b> RFC 8446 §4.1.3; Logjam paper (Adrian et al., 2015).

<b>Bottom line:</b> Eight reserved bytes of the server random act as a signed downgrade canary — a 1.3 client landing in a 1.2 handshake checks for "DOWNGRD" and aborts, turning a forced downgrade into a detectable, authenticated tamper.