Skip to content
ecdsa.com

Downgrade protection

Mechanisms that stop an attacker from forcing two parties that support a strong protocol version or algorithm onto a weaker one, such as the TLS 1.3 sentinel in ServerHello.random.
Also written asdowngrade attack protectionDOWNGRD sentinelTLS_FALLBACK_SCSV

TLS 1.3 servers that negotiate an older version must set the last 8 bytes of ServerHello.random to 44 4F 57 4E 47 52 44 01 (ASCII DOWNGRD plus 0x01) for TLS 1.2, or …00 for TLS 1.1 and below; TLS 1.3 clients receiving that must abort (RFC 9846 §4.2.3). Because the server random is covered by the server's signature, an attacker cannot remove it.

Earlier defenses: the TLS_FALLBACK_SCSV signaling value (RFC 7507) against browsers retrying with lower versions (the POODLE era), and the handshake transcript hash in Finished, which detects tampering with negotiated parameters. In TLS 1.2, downgrades to export or RSA key exchange (FREAK, Logjam) succeeded because servers still supported the weak options; disabling them is the real fix.

The same idea applies elsewhere: HSTS and MTA-STS prevent downgrades from HTTPS or STARTTLS to plaintext, and hybrid key exchange must not let a peer strip the post-quantum part, which is why it is negotiated as one group.

Standards and references

All terms