A post-quantum cryptography load balancer

Why this matters before the machines exist

The usual reaction is that quantum computers capable of breaking today's key exchange are years away, so this can wait. For most things that is true. For anything that has to stay secret for a long time, it is exactly backwards.

The attack is called harvest now, decrypt later. It does not require a quantum computer today. It requires a hard drive today and a quantum computer eventually. Somebody records your encrypted traffic now, keeps it, and reads it when the machines arrive. Every day you serve traffic with classic-only key exchange is a day of recordings that become readable later.

Hybrid, which is why it is safe to turn on

X25519MLKEM768 is a hybrid. It runs the classic X25519 exchange and the post-quantum ML-KEM exchange, and combines both results into the session key. An attacker has to break both.

That construction is the reason this is not a risky bet. ML-KEM is newer and has had less time under attack than the elliptic curves. If a weakness turns up in it, the classic half is still holding the door. You cannot end up worse off than you were with X25519 alone, so there is no trade to think hard about.

Using it as a PQC proxy

Your application almost certainly cannot do post-quantum TLS. It may be a Java service on an old runtime, a vendor appliance, or something whose build system nobody living understands. Waiting for every one of those to catch up is not a plan.

Terminate TLS at the load balancer instead. The visitor gets a post-quantum protected connection. The load balancer talks to the backend however that backend can manage, over a network you control. That is what a PQC proxy is, and it turns a problem spread across every application you run into a setting on one pair of servers.

Be honest with yourself about the second row. If the backend leg crosses a network you do not control, it needs its own protection, and post-quantum on the front does not give it that. Turn on backend TLS and verify the certificate properly.

Turning it on

1. Open the site, Settings tab, and tick Show advanced settings.
2. Under TLS, tick Post-quantum key exchange. This offers it and lets older clients fall back.
3. Leave Require post-quantum key exchange alone unless you control every client that connects. Requiring it turns older browsers away with an error nobody can act on.
4. Save, then Apply config.
5. Check it in a current browser. The security panel names the key exchange.

It needs TLS 1.3, which you want on anyway. The overhead is a slightly larger handshake, which is measured in kilobytes and happens once per connection.

What this does not cover

Key exchange is one part of TLS. The certificate itself is still signed with a classic algorithm, because the certificate authorities have not started issuing post-quantum signatures yet. That is a smaller worry: a signature has to be broken while the certificate is still valid to be useful to an attacker, and these certificates live ninety days. A recorded key exchange, by contrast, is useful forever.

So the priority order is right: protect the key exchange now, and the signatures will follow when the authorities are ready.