How to enable post-quantum cryptography and TLS termination with HAProxy

Every time a client connects to your server, a small negotiation happens before a single byte of application data moves. That negotiation, the TLS handshake, is what makes encrypted web traffic possible. It's also at risk of being recorded. Not the content of your sessions, but the handshake itself. And that's enough. A well-resourced attacker doesn't need to break your encryption today. They collect the handshakes now, wait until quantum computing matures, then use it to decrypt everything they've stored. The attack is called "harvest now, decrypt later.”

This isn't a general hacker concern. The actors with the means to store encrypted traffic at scale (and eventually acquire the quantum computing resources to break it) are nation-states and large, well-resourced organizations. The other important detail: you can't tell it's happening. Passive traffic collection leaves no trace, and waiting isn't a viable posture.

In August 2024, NIST responded to this threat by finalizing its first post-quantum cryptography (PQC) standards: ML-KEM for key encapsulation, and ML-DSA, SLH-DSA, and FN-DSA for digital signatures. 

This post covers what happens during a TLS handshake, why quantum computers threaten the key exchange step specifically, and how HAProxy can protect your traffic with hybrid post-quantum cryptography right now.

How does the TLS handshake work?

Every TLS connection begins with a handshake, a brief negotiation that establishes which cipher suite to use, authenticates the server, and derives the symmetric keys that protect the session. The cipher suite is the combination of algorithms and key lengths governing the session. The vulnerability that post-quantum cryptography addresses lives in one specific step of this process: the key exchange.

Modern TLS stacks, whether running 1.2 or 1.3, use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for that key exchange. Both sides contribute a fresh random value; the shared secret is derived from both contributions and immediately discarded. The classical security of ECDHE rests on the hardness of the elliptic curve discrete logarithm problem, which is effectively unsolvable on classical hardware. It is not unsolvable for a quantum computer running Shor's Algorithm.

TLS 1.3 (shown below) improves on 1.2 in ways that matter for this discussion: it makes ECDHE mandatory by removing static RSA key exchange, reduces the handshake to a single round-trip, and adds support for hybrid post-quantum key exchange. It also makes Perfect Forward Secrecy mandatory by design — more on that, and its limits, shortly.

Hybrid PQC requires TLS 1.3 because the named groups extension that carries the post-quantum component isn't available in TLS 1.2.

Hybrid key exchange

You'll see references to "hybrid key exchange" throughout this post. It means combining a classical algorithm (ECDHE) with a post-quantum algorithm (ML-KEM, or Module Lattice Key Encapsulation Mechanism) and using both outputs to derive the shared secret. Neither algorithm alone is enough to reconstruct it. It's a fail-safe in either direction: if ML-KEM has an undiscovered flaw, ECDHE still holds. If ECDHE is broken by a quantum computer, ML-KEM still holds. The hybrid approach also maintains backward compatibility, so clients that don't support post-quantum curves will negotiate classical ECDHE automatically.

If you want a deeper look at the mechanics of TLS 1.3 and round-trip improvements, we covered that in our TLS 1.3 & 0-RTT blog post.

Why do quantum computers break TLS?

Modern TLS key exchange relies on two math problems that are easy to compute forward and nearly impossible to reverse on classical hardware.

RSA depends on integer factorization. Multiplying two primes together is trivial: 17 × 23 = 391. Working backward from 391 to find 17 and 23 is manageable. Doing that with 600+ digit numbers is effectively impossible for any classical computer. ECDHE depends on the elliptic curve discrete logarithm problem, a different but similarly hard-to-reverse operation.

A sufficiently powerful quantum computer running Shor's Algorithm changes this, and Shor's Algorithm can solve both integer factorization and discrete logarithm problems efficiently. That means RSA and ECDHE, the two key exchange mechanisms securing virtually all classical TLS deployments, become breakable.

Quantum computers powerful enough to do this don't exist yet. But the timeline is shorter than most assume; Google's cryptography migration timeline puts the window at years, not decades. And there's a threat that doesn't require waiting for them.

ML-KEM is built on the Module Learning With Errors (MLWE) problem: given a system of linear equations with small random errors deliberately introduced, recovering the original values is computationally intractable even for a quantum computer. It doesn't reduce to factorization or discrete logs, so Shor's Algorithm does not apply. NIST standardized ML-KEM in 2024 because lattice problems of this kind are believed to be hard for both classical and quantum computers. You may also see it referred to by its earlier name, CRYSTALS-Kyber, which is still common in documentation and tooling.

If you want an interactive look at how Shor's Algorithm transforms factoring into period finding, this demo is worth a few minutes.

Perfect Forward Secrecy (PFS) and its limits

Perfect Forward Secrecy (PFS) is a property of certain key exchange mechanisms. When PFS is in place, each TLS session uses a completely independent, ephemeral key. Ephemeral means the key is generated fresh for that session and discarded immediately after. It's never stored on disk, never reused.

The practical upside: if an attacker later compromises your server's private key, they can't decrypt past sessions. Each session's secret is gone once the session ends.

PFS in TLS comes from ephemeral Diffie-Hellman key exchanges, specifically ECDHE. Both sides contribute a fresh random value per session. Neither side's value is ever reused. TLS 1.3 mandates PFS by removing static key exchange options entirely, which is one of the reasons it's a meaningful improvement over TLS 1.2.

But PFS has a limit that quantum computing exposes.

Why Perfect Forward Secrecy doesn't fully solve the quantum threat

A well-resourced attacker doesn't need to break encryption today. The strategy is to record encrypted TLS traffic now and wait until a cryptographically-relevant quantum computer exists, then use Shor's Algorithm to break the classical key exchange retroactively, sometimes described as "harvest now, decrypt later." It's a practical threat for any traffic containing data with a long sensitive shelf life: medical records, government communications, intellectual property.

PFS doesn't change this calculus, because the threat it protects against (an attacker stealing a server's long-term private key) is a different threat model entirely.  What Shor's Algorithm targets is the ephemeral key exchange itself, by solving the discrete logarithm problem against the recorded handshake. That handshake was transmitted in plaintext and is straightforward to capture passively, without any access to the server. Forward secrecy was designed for a world where breaking the key exchange was computationally out of reach, and that assumption no longer holds.

Hybrid post-quantum key exchange addresses this directly. By combining ECDHE with ML-KEM, breaking the shared secret requires defeating both algorithms simultaneously, and Shor's Algorithm currently cannot be used against the lattice-based component.

Configuring hybrid post-quantum cryptography in HAProxy

HAProxy Enterprise 3.2+ and HAProxy Community 3.3+ support hybrid post-quantum cryptography natively. This works because both versions ship with AWS-LC as their cryptographic library, which includes support for post-quantum curves. See our Supercharging HAProxy Community with AWS-LC Performance Packages blog post for details on the AWS-LC integration, and the AWS-LC PQ documentation for the full list of supported curves.

Hybrid PQC also requires TLS 1.3. The key exchange mechanisms that carry the post-quantum component, specifically the named groups extension, aren't available in TLS 1.2. The configuration below sets ssl-min-ver TLSv1.3 on both bind and server sides to enforce this. If you have clients that can't do TLS 1.3, they won't reach the post-quantum path regardless of curve configuration.

Here's a working configuration that enables hybrid PQC. The PQC-specific addition is two lines: the curve priority lists for bind and server sides. Everything else in the configuration below is standard TLS hardening we'd recommend regardless of post-quantum requirements.

The curve order matters:

HAProxy tries the hybrid post-quantum curves first. If the client doesn't support them, it falls back to X25519, then P-384, then P-256. No manual intervention needed, just a graceful fallback to classical ECDHE for clients that aren't ready yet.

Testing the connection

You can verify hybrid PQC is negotiating correctly with BoringSSL's bssl client, which ships with HAProxy Community and HAProxy Enterprise packages by default. The path varies by version (this example uses HAProxy Enterprise 3.2), so adjust accordingly:

A successful connection shows the negotiated group in the output:

Note: curl requires OpenSSL 3.5.0 or later for post-quantum hybrid curves — OpenSSL 3.5.0 (released April 2025) is the first version with native PQC support. Older versions require the OQS provider and will otherwise fail or fall back to classical ECDHE. Use bssl for testing.

Once this configuration is in place, your TLS handshake follows a path that classical and quantum computers can't break independently:

Implement post-quantum cryptography now

Quantum computers that can break RSA and ECDHE don't exist yet. But adversaries can and do collect encrypted traffic today against the day when they will. NIST finalized its first post-quantum cryptography standards in 2024, and the ecosystem is moving fast.

HAProxy with AWS-LC gives you hybrid PQC without waiting for clients to catch up. The fallback curve order handles compatibility automatically. 

PQC carries a slight CPU penalty once enabled, but for most workloads this trade-off is worth taking. We have benchmarked both standard TLS and PQC-enabled TLS, and will publish the results in a follow-up blog post.

What’s next?

Migrating key exchange now is step one of a two-phase migration. Digital signatures are step two.

Hybrid ML-KEM key exchange protects the key agreement step of the TLS handshake, but TLS also uses digital signatures to authenticate certificates. Those signatures still rely on RSA or ECDSA, which are equally vulnerable to Shor's algorithm.

The NIST PQC standard includes ML-DSA (CRYSTALS-Dilithium) and SLH-DSA for post-quantum digital signatures. Support in certificate authorities and TLS stacks is coming.

One note on scope: HAProxy secures the client-to-edge connection. Traffic from HAProxy to your backend applications travels over a separate connection, and if those backends don't yet support PQC, that leg stays on classical crypto. Enabling PQC at the edge is still the right first step because it's the most exposed connection for passive collection. But a complete migration requires applying the same approach to your backend connections.

FAQs

Glossary

Subscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.