What actually prevents an attacker from forcing a TLS 1.3 client down to TLS 1.2?

What actually prevents an attacker from forcing a TLS 1.3 client down to TLS 1.2?

The defense is a clever sentinel hidden in the server's random field, and it is worth reading precisely because version downgrade was a recurring class of attack.

TLS version negotiation is vulnerable because the ClientHello is sent in the clear. A network attacker can tamper with the offered versions, tricking peers into a weaker protocol — the lineage of FREAK, Logjam, and POODLE all involve forced downgrade or weak-parameter coercion.

TLS 1.3 (RFC 8446 §4.1.3) adds an integrity-checked tripwire. When a server that supports TLS 1.3 is nonetheless negotiating TLS 1.2 or below — whether legitimately or because an attacker stripped the supported_versions extension — it writes a specific 8-byte sentinel into the last bytes of its ServerHello Random field: 44 4F 57 4E 47 52 44 01 for 1.2, ending 00 for older. ("DOWNGRD" in ASCII.)

Because the ServerHello Random is covered by the handshake's signature/Finished verification, a genuine TLS 1.3 client that ends up on 1.2 will see this sentinel and know a real 1.3-capable server was on the other end. If it expected 1.3, it aborts — the attacker cannot remove the sentinel without breaking the authenticated handshake transcript.

Further reading: RFC 8446 §4.1.3; the Logjam and FREAK papers (2015).

Bottom line: TLS 1.3 embeds a signed "DOWNGRD" sentinel in ServerHello.Random so a downgraded-but-1.3-capable handshake is cryptographically detectable and aborted.