CONCEPT Cited by 1 source

Downgrade attack¶

Definition¶

A downgrade attack is an active-adversary manipulation of a cryptographic protocol negotiation that forces the two endpoints to select a weaker algorithm (or a lower protocol version) than either side actually prefers. Exploits the fact that protocols designed for crypto-agility typically support a range of algorithms for backward compatibility; an attacker sits in the middle of the handshake and strips the stronger options from one side's advertised list so the intersection falls to a weaker choice.

Downgrade attacks are the dual of algorithm-negotiation's main benefit: the same flexibility that lets new primitives deploy without breaking old clients also creates a target surface for forcing weaker primitives.

Canonical shapes¶

SSL/TLS version downgrade — before TLS 1.3, an attacker could truncate the ClientHello and force TLS 1.0 / SSL 3.0 selection (POODLE, 2014).
TLS cipher-suite downgrade — FREAK (2015), Logjam (2015) forced export-grade RSA / DH primes from the 1990s that were still in allowed cipher lists.
STARTTLS stripping — SMTP / IMAP attacker drops the STARTTLS advertisement from the server's response; client continues in plaintext.
HSTS-less HTTP→HTTPS strip — sslstrip (2009) — attacker serves HTTP proxy to a client that would otherwise have gone HTTPS.
WPA/WPA2 downgrade — KRACK-adjacent attacks on 4-way handshake renegotiation.

Transcript binding: the standard mitigation¶

The structural defense is to cryptographically bind the handshake negotiation into the session key or into an explicit authenticator, so any attacker modification of the advertised algorithm lists becomes detectable after the fact:

TLS 1.3 signs the handshake transcript — both sides verify.
SSH includes both KEXINIT messages verbatim in the exchange-hash.
QUIC binds transport parameters into the key schedule.

With transcript binding the attacker still controls the wire, but cannot produce a valid Finished / signature over the altered transcript without the long-term authentication key.

The post-quantum downgrade problem¶

The classical downgrade attacks above are all about forcing classically-weaker primitives. Post-quantum introduces a new shape: an attacker with a CRQC can forge transcript signatures under classical RSA / ECDSA long-term keys. Transcript binding no longer protects the downgrade, because the adversary can forge the signature that would normally detect tampering.

This is the insight behind the 2026 Cloudflare observation:

Adding support for PQ cryptography is not enough. Systems must disable support for quantum-vulnerable cryptography to be secure against downgrade attacks. (Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

Enabling PQ hybrid KEM (e.g. X25519MLKEM768) means that a CRQC-equipped attacker cannot passively decrypt the session — so HNDL is defeated. But the attacker can still actively downgrade the handshake to force selection of classical-only negotiation, MITM the session, and forge the server's classical signature. The negotiation is secure against classical downgrade attempts via transcript binding; it is not secure against quantum downgrade attempts because the transcript signature itself is forgeable.

Why disabling classical isn't easy¶

The natural fix — remove classical signatures from the server's advertised list entirely — is not feasible for open federated systems:

The public web has a long tail of clients that don't yet support PQ signatures and won't upgrade on any reasonable timeline.
Servers that unilaterally disable classical break browsing for those clients → business outage.
Coordinated industry-wide cutover is organisationally impossible for the public Internet.

So the ecosystem is developing alternative downgrade-protection surfaces that operate outside the connection-level negotiation:

PQ HSTS — HSTS-style browser policy header: once a site says "I speak PQ authentication", browsers refuse to accept classical signatures from that origin going forward, even if the handshake negotiates them. Analogous to HSTS forcing HTTPS after a first successful HTTPS visit.
Certificate transparency- based downgrade detection — public logs let the client observe whether PQ certificates exist for the origin; if so and the handshake offers only classical, the client treats that as an attack. See Bas Westerbaan's RWPQC 2026 slides.
Client-side pinning — custom enterprise deployments can pin PQ cert / algorithm per origin.

For closed systems (internal service meshes, enterprise VPN, SSH within a controlled org) disabling classical is feasible — no heterogeneous client base — and should be done aggressively once PQ is deployed.

The sequence: enable-PQ → disable-classical → rotate¶

Captured in patterns/disable-legacy-before-rotate:

Enable PQ primitives alongside classical (algorithm negotiation picks PQ for capable clients, falls back to classical for the rest).
Disable classical — on the closed-system side, forcibly; on the open-system side, via PQ HSTS + CT-based downgrade detection.
Rotate all secrets that might have leaked through the now- disabled classical sessions. An attacker who was waiting for Q-Day now has decrypted captures; every password / API key / token in those captures is burned.