A TLS downgrade attack is a type of man-in-the-middle attack where an adversary forces a connection between a client and server to use an older, weaker version of the TLS (Transport Layer Security) protocol — even when both parties support a newer, more secure one.

This is particularly relevant in the context of Post-Quantum Cryptography (PQC): a server may support quantum-resistant key exchange via TLS 1.3, but if it also allows TLS 1.2 or earlier, an attacker can force the connection to fall back to classical cryptography — completely bypassing the PQC protection.

At QuReady, we consider downgrade attacks the biggest blind spot in PQC migration today.

How Does It Work?

1. Interception: The attacker positions themselves between the client and server (a classic man-in-the-middle scenario — on a network, at a router, via DNS hijacking, etc.).

2. Handshake Manipulation: When the client sends its initial TLS ClientHello message advertising support for TLS 1.3 (with PQC key exchange groups like X25519MLKEM768), the attacker modifies or blocks the message to remove the newer protocol options.

3. Forced Fallback: The server receives a ClientHello that only advertises older protocol versions (TLS 1.2, 1.1, or 1.0). Since the server still supports these for backwards compatibility, it accepts and negotiates the older version.

4. Classical Key Exchange: The connection now uses classical key exchange (ECDHE or RSA) instead of the quantum-resistant algorithm. The session’s forward secrecy relies entirely on the difficulty of problems a quantum computer can solve.

5. Harvest or Decrypt: The attacker can either decrypt the session immediately (if they’ve compromised the classical key exchange) or record the traffic for future decryption when quantum computers become available — a harvest now, decrypt-later attack.

Why Is This Critical for PQC?

The entire point of deploying Post-Quantum Cryptography is to protect data against quantum-capable adversaries. But PQC algorithms are only negotiated over TLS 1.3. If a server also accepts TLS 1.2 connections, the quantum protection is optional — and an active attacker can opt out of it on behalf of the user.

This means:

• Deploying PQC while allowing TLS 1.2 does not guarantee quantum-safe connections
• A sophisticated adversary (nation-state, APT) can selectively downgrade high-value targets
• Recorded downgraded sessions are just as vulnerable to future quantum decryption as sessions from servers with no PQC at all

Our PQC Domain Checker tests for this exact vulnerability: it verifies not only whether a domain supports PQC, but also whether older TLS versions remain enabled.

Historical Precedent

Downgrade attacks are not theoretical — they have been exploited repeatedly in the wild:

• POODLE (2014): Forced connections from TLS to SSL 3.0, exploiting a padding oracle vulnerability
• FREAK (2015): Downgraded connections to export-grade RSA (512-bit keys), breakable in hours
• Logjam (2015): Forced 512-bit Diffie-Hellman key exchange, allowing passive decryption
• DROWN (2016): Exploited servers supporting SSLv2 to decrypt TLS connections

Each of these demonstrated the same lesson: supporting legacy protocols creates exploitable attack surface, regardless of how strong your primary protocol is.

The PQC Downgrade Problem in Numbers

Data from our PQC Domain Checker shows that among domains supporting Post-Quantum Cryptography:

• Only approximately 1 in 6 are fully quantum-safe (PQC enabled + no legacy TLS)
• The remaining 5 in 6 still accept TLS 1.2, leaving them vulnerable to forced downgrade
• This includes virtually all major technology companies, financial institutions, and cloud providers

The industry has adopted PQC faster than expected — but has not yet taken the harder step of removing legacy protocols.

Why Do Servers Still Allow Older TLS?

The primary reason is backwards compatibility:

• Older browsers and operating systems (particularly in enterprise environments) may not support TLS 1.3
• IoT devices and embedded systems often use outdated TLS libraries
• Some regulatory or contractual requirements mandate supporting older clients
• CDNs and load balancers default to broad protocol support

While these are legitimate operational concerns, they must be weighed against the security cost — especially for organizations handling long-lived sensitive data.

Mitigating Downgrade Attacks

1. Disable TLS 1.0 and 1.1 immediately: These protocols are deprecated (RFC 8996, March 2021) and have no legitimate modern use case. If you haven’t done this yet, it should be a priority regardless of PQC.

2. Plan TLS 1.2 deprecation for sensitive services: Segment your infrastructure so that endpoints handling sensitive data only serve TLS 1.3. Use monitoring to measure the actual percentage of TLS 1.2 traffic — it’s often negligible.

3. Use TLS 1.3 Downgrade Sentinel: TLS 1.3 includes a built-in downgrade detection mechanism (RFC 8446 §4.1.3) where the server embeds a sentinel value in the ServerHello random field when downgrading. Ensure your clients validate this.

4. Deploy HSTS and HSTS Preloading: While HSTS doesn’t prevent TLS version downgrades directly, it prevents protocol downgrades from HTTPS to HTTP — another vector in the same attack family.

5. Monitor for downgrade attempts: Log and alert on TLS 1.2 connections to endpoints that should be TLS 1.3-only. Unexpected fallback connections are a strong indicator of active attack.

6. Test your domains regularly: Use our PQC Domain Checker to verify that your PQC deployment achieves full quantum-safety, not just partial protection.

The Bottom Line

Deploying PQC without disabling legacy TLS is like installing a quantum-resistant lock on your front door while leaving the back door open. An attacker doesn’t need to break PQC — they just need to convince your server to not use it.

Full quantum-safety requires both:

• ✅ Post-Quantum key exchange (ML-KEM / X25519MLKEM768)
• ✅ Elimination of downgrade paths (TLS 1.3 only)

At QuReady, we help organizations achieve both. Check your domain to see where you stand, or contact us for a comprehensive PQC readiness assessment.