up:: In the Protocols MOC

Downgrade and Rollback Attacks

A downgrade attack is when an adversary who cannot break the strong cryptography on a connection instead interferes with the negotiation that chooses the algorithm, steering both sides onto a weaker option that the attacker can defeat. It targets the handshake rather than the math itself. Every protocol that supports a choice of algorithms has to negotiate which to use, and that negotiation is a step an attacker on the path can try to rewrite. In the post-quantum transition this matters intensely, because a connection can advertise hybrid or post-quantum key exchange and still end up running classical-only ECDH if a middlebox drops the larger handshake or an attacker strips the strong option, which reopens the exact harvest-now-decrypt-later exposure the migration was meant to close.

The short version:

• A downgrade attack forces a connection off its strong algorithm and onto a weak one by tampering with negotiation, so the attacker never has to break the strong cryptography at all.
• The rule this teaches is that “PQC is offered” is a different claim from “PQC is used.” A server that advertises hybrid key exchange but falls back to classical-only on some paths has not closed its harvest-now-decrypt-later window on those paths.
• Hybrid key exchange has to fail safe, meaning the session is secure if either the classical or the post-quantum half holds. The security only survives when a stripped or corrupted negotiation causes a visible failure rather than a silent drop to the weaker algorithm.
• TLS 1.3 hardens against this with an authenticated transcript: the Finished message runs a MAC over the whole handshake, so tampering breaks the connection, and a sentinel in the server’s random value catches an attacker trying to force the peer down to TLS 1.2 or below.
• The practical consequence is that verification is part of the deployment. You confirm the negotiated group on real traffic, because a downgraded connection still succeeds and still looks healthy while quietly using cryptography a quantum computer breaks.

Picture two people agreeing on a language to speak before a meeting, shouting their options across a crowded room. Each lists the languages they know, in order of preference, and they settle on the strongest one both share. Now put a saboteur in the middle who can quietly cross items off each list before the other side hears them. The saboteur never has to understand a word of the conversation that follows. They just erase every option except the one they happen to have a dictionary for, and both parties, believing they picked the best shared language, proceed in the weakest. That erasure is the whole shape of a downgrade attack, and defending against it means making any tampering with the lists loud enough to abort the meeting.

What is a downgrade attack?

A downgrade attack, sometimes called a rollback attack, is an active manipulation of the negotiation phase of a protocol that ends with the two endpoints agreeing on a weaker algorithm, protocol version, or parameter set than both were willing and able to use. The attacker sits on the network path as a machine-in-the-middle and edits the negotiation messages, removing the strong choices from the menu or forging a response that claims the strong option is unavailable, so the honest fallback logic on each side settles for something the attacker can already break or record for later.

The defining feature is that the attacker never touches the cryptography that does the actual protecting. Breaking modern elliptic-curve or ML-KEM key exchange head-on is infeasible today, so an adversary who wants the data takes the cheaper path and attacks the choice of algorithm instead of the algorithm. Historically this has been one of the most productive families of real attacks on TLS: FREAK and Logjam both worked by forcing servers back onto deliberately weakened “export-grade” cryptography that governments had once mandated, and POODLE worked by forcing a rollback to the ancient SSL 3.0. In each case the strong cryptography on the connection was fine. The negotiation that selected it was the target.

Source: Beurdouche et al., “A Messy State of the Union: Taming the Composite State Machines of TLS,” IEEE S&P 2015 (the FREAK downgrade to export-grade RSA), mitls.org/pages/attacks/SMACK; Adrian et al., “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice,” ACM CCS 2015 (the Logjam downgrade to export-grade Diffie-Hellman), weakdh.org.

How does a downgrade attack threaten a PQC migration?

The post-quantum transition creates a fresh and specific downgrade surface, because for the length of the migration nearly every quantum-safe connection is also willing to speak classical cryptography. That dual willingness is deliberate. It is how a server stays reachable by peers that have not migrated yet, and it is the whole logic of running hybrid key exchange during the transition. The catch is that anything a connection is willing to fall back to is something an attacker can try to force it back to.

The threat model splits into two cases worth naming separately, because they call for different fixes.

1. Active stripping. An adversary on the path edits the ClientHello to remove the hybrid or post-quantum group from the client’s supported_groups list, or forges a server response indicating the strong group is unsupported, so the honest fallback logic selects a classical curve. This is the classic machine-in-the-middle downgrade, and it is defeated by authenticating the negotiation so tampering is detectable.
2. Passive fallback that looks like success. No attacker is even required. A middlebox on the path drops the oversized post-quantum ClientHello because it exceeds a size the box assumed handshakes would never reach, and the client silently retries with a classical-only handshake that fits. The connection succeeds, the user sees a padlock, and the traffic is classical-only and harvestable, with no error anywhere to flag it.

The second case is the quieter danger, because it produces no alarm and no attacker to catch. It is the same protocol-ossification failure documented in hybrid TLS and hybrid cryptography generally: two perfectly configured post-quantum endpoints still run classical-only if a legacy device between them refuses the larger handshake. From a harvest-now-decrypt-later standpoint, a silent fallback and a successful active strip leave the same recording on the wire.

What does “fail safe” mean for hybrid key exchange?

Fail safe means that when something goes wrong in the negotiation, the connection ends up in the secure state, which for a hybrid mechanism is a failure the operator can see rather than a silent slide to the weaker algorithm. The security property the standards promise for hybrid is that a session “remains secure as long as one of the component key exchange mechanisms remains unbroken,” and that property is real only if the combined secret genuinely depends on both halves at once.

Source: Stebila, Fluhrer, Gueron, “Hybrid key exchange in TLS 1.3,” IETF, draft-ietf-tls-hybrid-design.

This is where the construction earns its safety. In X25519MLKEM768 the two shared secrets are concatenated and fed together into the TLS key schedule, so every downstream key is derived from both the classical and the post-quantum secret. An attacker who breaks or strips one component still needs the other to compute the session key, which is exactly the guarantee. The dangerous alternative is a design that would let a connection quietly drop from the hybrid group to a classical group when the hybrid negotiation runs into trouble. That design is a hybrid that failed open, because the endpoint that thinks it negotiated hybrid is now running classical-only with no way to know. Fail-safe hybrid means the outcome is hybrid or a visible failure, and never a silent classical fallback that presents itself as success.

Negotiation outcome	What the endpoint believes	What is actually protecting the traffic	Harvest-now-decrypt-later exposure
Hybrid negotiated (fail safe)	Hybrid	Classical secret and ML-KEM secret combined	Closed
Visible failure on tampering (fail safe)	Connection aborted	Nothing, and the operator sees it	None, forces a fix
Silent classical fallback (fail open)	Hybrid	Classical key exchange alone	Open, and invisible

How does TLS 1.3 protect against being forced downhill?

TLS 1.3 was designed after the FREAK, Logjam, and POODLE downgrades, and it builds downgrade resistance into the protocol with two mechanisms that together make tampering with the handshake break the connection instead of weakening it.

1. The whole handshake is authenticated by the Finished message. TLS 1.3 computes a MAC over a running transcript hash of every handshake message and exchanges it in the Finished message before any application data flows. RFC 8446 describes this value as “a MAC over the entire handshake.” If an attacker edited the ClientHello to strip a strong group, the transcript each side hashes stops matching, the MAC check fails, and the connection aborts rather than proceeding on the weakened choice.
2. A version-downgrade sentinel in the server random. To catch an attacker forcing a rollback to an older TLS version whose handshake was less protected, a TLS 1.3 server that finds itself negotiating down to TLS 1.2 writes a fixed marker into the last 8 bytes of its ServerHello random. RFC 8446 §4.1.3 specifies that “if negotiating TLS 1.2, TLS 1.3 servers MUST set the last 8 bytes of their Random value to the bytes: 44 4F 57 4E 47 52 44 01” (the ASCII string “DOWNGRD”), and a client that expected TLS 1.3 “MUST check that the last 8 bytes are not equal to either of these values” and abort if they are.

Source: Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” IETF, RFC 8446 (downgrade sentinel §4.1.3, Finished MAC over the handshake §4.4.4).

The consequence for a post-quantum rollout is that active machine-in-the-middle stripping of the hybrid group from a genuine TLS 1.3 handshake is caught by the transcript MAC, which is a strong and welcome protection. It is the passive-fallback case, where the client itself chooses to retry classical-only after a middlebox drops the large handshake, that these mechanisms do not cover, because there the endpoint made the downgrade decision voluntarily and there is nothing dishonest in the transcript to detect.

Why is “PQC is offered” not the same as “PQC is used”?

Because a connection can advertise a post-quantum group and still complete on a classical one, so the presence of the option in a config file or a supported_groups list is evidence of intent, not evidence of protection. This is the load-bearing distinction of the whole note, and it is where most confident-but-wrong migration status reporting comes from.

A server operator can enable X25519MLKEM768, watch it appear in the handshake capture of a test connection from a modern browser, and reasonably conclude the endpoint is migrated. What that test does not show is the population of real clients and paths where hybrid quietly does not happen: an older client that never offers the group, a corporate proxy that strips it, a load balancer that drops the oversized ClientHello, or a mobile network path with a middlebox that cannot carry the larger handshake. On every one of those connections the server is willing to speak hybrid and speaks classical-only instead, and each of those sessions is harvestable. A migration that measures “did we enable it” instead of “what fraction of real traffic negotiated it” is measuring the wrong thing.

The correct instrument is negotiation telemetry from production. You measure the share of real handshakes that selected the hybrid group, watch that number over time, and treat the gap between offered and used as the actual state of the migration. A dashboard that reads 100% enabled and 60% negotiated is telling you 40% of your traffic is still harvestable, which is a truth no config audit could surface.

How do you detect and prevent downgrade in a rollout?

Detection is a wire-and-telemetry problem and prevention is a policy problem, and a serious rollout does both rather than trusting that enabling the option finished the job.

1. Measure the negotiated group on production traffic, not test traffic. Instrument servers and load balancers to record which key-exchange group each handshake actually selected, and report the fraction that landed on the hybrid group. This is the single most important number in a key-exchange migration, and it is the only one that distinguishes offered from used.
2. Confirm on the wire in spot checks. A packet capture shows the negotiated group directly. For X25519MLKEM768 the selected-group value on the wire is 0x11EC, and the kilobyte-scale key_share confirms hybrid was genuinely chosen rather than merely listed.
3. Watch the handshake-failure and retry rate as you roll out. The passive-fallback failures from oversized ClientHellos surface as connection errors or classical-only retries from specific network paths, so a rising retry rate is the tell that a middlebox on some route is forcing the downgrade.
4. Decide the fallback policy deliberately, per data class. For most public web traffic, silent classical fallback preserves reachability and is an acceptable transition compromise. For a link carrying long-lived secrets where harvest-now-decrypt-later is the whole threat, the safer posture is to refuse the connection rather than complete it classical-only, so a downgrade becomes a visible failure that gets fixed instead of a quiet exposure that persists.

Source: RFC 8446 (negotiated group carried in supported_groups §4.2.7 and the ServerHello selected group); draft-ietf-tls-ecdhe-mlkem (the X25519MLKEM768 codepoint 0x11EC).

The through-line is that a downgrade defense is not a setting you flip once. It is a measurement you keep, because the failure mode is invisible by construction: a downgraded connection succeeds. The only way to know your post-quantum key exchange is protecting real traffic is to look at real traffic and count.

Common misconceptions

• “If my server supports hybrid, my connections are quantum-safe.” Support is willingness, and a connection can be willing to speak hybrid and complete on classical because a client, proxy, or middlebox on the path forced the weaker choice. Only the negotiated group on real traffic tells you what was actually used.
• “A downgrade attack means the attacker broke the encryption.” The opposite. A downgrade attack is what an adversary does precisely because they cannot break the strong cryptography, so they attack the negotiation and force the connection onto something they can already defeat.
• “TLS 1.3 fixed downgrades, so I do not have to worry.” TLS 1.3’s transcript MAC defeats an active attacker who edits the handshake, which is a real and important protection. It does not cover the case where the client itself voluntarily retries classical-only after a middlebox drops the oversized post-quantum ClientHello, because that transcript is honest.
• “Hybrid key exchange is safe as long as the post-quantum half is strong.” Only if the negotiation fails safe. A hybrid design that silently drops to a classical group when the hybrid handshake runs into trouble hands an attacker the downgrade for free, because the endpoint believes it negotiated hybrid while running classical-only.
• “A silent classical fallback is harmless because the connection still encrypts.” It encrypts with the exact algorithm a quantum computer breaks, so from a harvest-now-decrypt-later standpoint a silent fallback records the same exposed traffic as a successful active downgrade. Harmless-looking is the danger.

Questions people ask

What is the difference between a downgrade attack and breaking the cryptography? Breaking the cryptography means defeating the algorithm directly, which is infeasible for modern key exchange. A downgrade attack sidesteps that entirely by tampering with the negotiation so the connection selects a weaker algorithm the attacker can already defeat, so the strong cryptography is never even engaged.

Does enabling hybrid key exchange guarantee my traffic uses it? No. Enabling it means your endpoint is willing to negotiate it, but a peer that does not offer the group, an attacker who strips it, or a middlebox that drops the oversized handshake can all result in a classical-only connection that still succeeds. You confirm the negotiated group on real traffic to know it was used.

How does TLS 1.3 stop an attacker from forcing my connection down? It authenticates the entire handshake with a MAC in the Finished message, so an attacker who edits the negotiation breaks the connection instead of weakening it, and it plants a “DOWNGRD” sentinel in the server random to catch a forced rollback to an older TLS version. Both make active tampering a visible failure.

Why does the guide keep saying to verify on the wire? Because a downgraded or fallen-back connection succeeds and looks completely normal, padlock and all, so there is no user-visible symptom. The only reliable evidence that post-quantum key exchange protected a session is the negotiated group in the handshake itself, which is why verification is treated as part of the deployment.

Is a middlebox forcing classical-only actually an attack? Not in the malicious sense, but the outcome is identical to one. The connection runs classical-only key exchange and is harvestable, so whether a hostile actor stripped the strong group or a legacy box quietly dropped the large handshake, the recording an adversary keeps for a future quantum computer is the same, and both belong in the same threat model.

Should I ever refuse a connection rather than fall back to classical? For links carrying long-lived secrets, yes. When harvest-now-decrypt-later is the whole point, a visible failure that gets fixed is safer than a silent classical fallback that quietly persists, so a strict no-downgrade policy on those specific paths turns an invisible exposure into an actionable error.

---

Everything here is the map, given freely. When your team needs its own protocols and network paths assessed for silent downgrade, so “PQC enabled” becomes “PQC provably used” on real traffic, that’s what an alignment briefing is for.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.