Post-Quantum Cryptography with NGINX and Angie: ML-KEM, Hybrid TLS and Why Your HTTPS Needs a Quantum Upgrade

Okay, real talk. You know that little padlock in your browser when you visit a website? That padlock is basically the whole foundation of internet security. It means your connection is encrypted — nobody in the middle can read what you’re sending. Passwords, bank details, those embarrassing messages you send at midnight — all protected by that tiny padlock.

Here’s the thing though: quantum computers are coming. And when they arrive in full force, that padlock? Gone. Like, completely destroyed. Quantum computers can theoretically crack the math behind today’s encryption in hours instead of centuries. And no, this isn’t sci-fi. It’s why cryptographers have been quietly panicking for years and building the replacement right now.

That replacement is called post-quantum cryptography, or PQC. And the good news is — NGINX and Angie already support it. This guide explains what it is, why it matters, and exactly how to turn it on. No PhD required.

Wait, How Does Quantum Break Encryption?

Here’s the simplest possible explanation. Today’s HTTPS encryption relies on a very clever trick: multiplying two huge prime numbers together is easy, but factoring the result back into those two primes is insanely hard. It would take a classical computer (the kind you’re reading this on) billions of years. So your secrets are safe.

Quantum computers use something called Shor’s algorithm which can factor those huge numbers exponentially faster. In practice, a sufficiently powerful quantum computer could crack RSA-2048 (today’s standard) in hours. Suddenly your “billions of years” becomes “time for a coffee break.”

There’s also the chilling threat called “Harvest Now, Decrypt Later.” Nation-state actors are already recording encrypted traffic today, storing it, and waiting for quantum computers to arrive so they can decrypt it later. If you’re transmitting anything sensitive that should stay secret for 10+ years? The risk is real right now.

What Is Post-Quantum Cryptography?

Post-quantum cryptography is encryption built on math problems that are hard for both classical AND quantum computers. Researchers spent decades finding these problems. The winner, chosen by NIST (America’s standards body) after a global competition, is called ML-KEM — Module-Lattice-Based Key-Encapsulation Mechanism. Yes, that’s a mouthful. It used to be called Kyber, which is a much cooler name, honestly.

ML-KEM is based on “lattice problems” — a type of geometric math that even quantum computers can’t solve efficiently. Think of it like a scrambled Rubik’s Cube in 1,000 dimensions. Good luck with that.

The main post-quantum algorithms you’ll hear about are:

• ML-KEM (was: Kyber) — for key exchange. This is the one used in TLS hybrid mode.
• ML-DSA (was: Dilithium) — for digital signatures. Used to sign certificates.
• SLH-DSA (was: SPHINCS+) — hash-based signatures, conservative and battle-tested.

Hybrid TLS: The Best of Both Worlds

Here’s the dilemma: you can’t just switch to pure post-quantum TLS overnight. Your visitors’ browsers and old devices might not support it. You’d break compatibility for half your users. Not ideal.

The solution is hybrid TLS: run both a traditional key exchange (like X25519, the current gold standard) AND a post-quantum one (ML-KEM) simultaneously. The final encryption key combines both. An attacker needs to break both algorithms to crack your connection. Even if their quantum computer defeats X25519, ML-KEM still holds. Even if ML-KEM has an unknown weakness, X25519 still holds. It’s belt-and-suspenders security.

The hybrid cipher suite is called X25519MLKEM768. Google Chrome has been sending it to every website since 2024. If your server supports it, Chrome automatically uses it. You might already be doing post-quantum TLS for Chrome users without knowing it — if you’ve got a modern enough OpenSSL.

NGINX and Angie: Do They Support Post-Quantum TLS?

Yes — and here’s the beautiful part. You don’t need special NGINX patches. Post-quantum support lives in OpenSSL 3.5+, which includes ML-KEM. When NGINX uses OpenSSL 3.5+, it automatically offers X25519MLKEM768 to clients that support it. Chrome uses it, Firefox is adding it, and the rest will follow.

At deb.myguard.nl, we build a dedicated openssl-nginx package tuned specifically for NGINX and Angie. Our OpenSSL 4.0 build includes full ML-KEM support, kTLS offloading, hardware entropy (RDRAND), and all the post-quantum goodness. Install it and your NGINX is immediately quantum-ready.

The same applies to Angie — our Angie packages link against openssl-nginx and support hybrid TLS out of the box.

How to Configure Hybrid TLS in NGINX/Angie

Good news: the configuration is minimal. With OpenSSL 3.5+ (or our openssl-nginx 4.0 package), ML-KEM hybrid is offered automatically in TLS 1.3. You just need to make sure you’re not accidentally disabling it.

Basic TLS 1.3 config that enables hybrid PQC:

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate     /etc/nginx/certs/cert.pem;
    ssl_certificate_key /etc/nginx/certs/key.pem;

    # TLS 1.3 only: ML-KEM hybrid key exchange is automatic
    ssl_protocols TLSv1.3;

    # Or if you need TLS 1.2 compatibility too:
    # ssl_protocols TLSv1.2 TLSv1.3;
    # ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:TLS_AES_256_GCM_SHA384;
}

That’s it. No special ssl_ecdh_curve directives needed — OpenSSL 3.5 handles X25519MLKEM768 automatically in TLS 1.3 negotiations.

To explicitly configure the key exchange groups (useful for controlling exactly which PQC groups you offer):

server {
    listen 443 ssl;

    ssl_protocols TLSv1.3;
    ssl_certificate     /etc/nginx/certs/cert.pem;
    ssl_certificate_key /etc/nginx/certs/key.pem;

    # Explicitly set hybrid PQC + classical groups
    # X25519MLKEM768 = hybrid post-quantum key exchange
    # x25519 = fallback for clients that don't support PQC yet
    ssl_ecdh_curve X25519MLKEM768:x25519:secp256r1:secp384r1;
}

Verify Post-Quantum Is Working

After reloading NGINX (nginx -s reload), test your connection:

# Check what key exchange group was negotiated
openssl s_client -connect yourdomain.com:443 -tls1_3 2>&1 | grep -i "server temp key"

# You want to see something like:
# Server Temp Key: X25519MLKEM768, ...

# Or use curl with verbose output:
curl -v https://yourdomain.com 2>&1 | grep -i "SSL connection"

Generating Post-Quantum Certificates (The Next Frontier)

Hybrid TLS solves the key exchange problem. But there’s another piece: certificate signatures. Right now, your Let’s Encrypt certificate is signed with ECDSA — which quantum computers can also attack. Let’s Encrypt and the major CAs are working on post-quantum certificate signing, but it’s not quite mainstream yet.

For testing and internal use, you can generate a post-quantum self-signed cert with OpenSSL 4.0:

# Generate an ML-DSA-65 private key (post-quantum signature algorithm)
openssl genpkey -algorithm ML-DSA-65 -out pqc_key.pem

# Create a certificate signing request
openssl req -new -key pqc_key.pem -out pqc.csr -subj "/CN=yourdomain.com"

# Self-sign the certificate
openssl x509 -req -days 365 -in pqc.csr -signkey pqc_key.pem -out pqc_cert.pem

# Use it in NGINX
# ssl_certificate     /etc/nginx/certs/pqc_cert.pem;
# ssl_certificate_key /etc/nginx/certs/pqc_key.pem;

Note: browsers won’t trust self-signed certs in production. For now, use regular Let’s Encrypt certs for the certificate part and let OpenSSL handle PQC at the key exchange level. The full post-quantum certificate chain is coming as CAs adopt ML-DSA signing.

Achieving A+ on SSL Labs With Post-Quantum

Post-quantum TLS and SSLLabs A+ are best friends. The hybrid approach is fully compatible with getting top scores. Make sure you:

• Use TLS 1.3 (required for ML-KEM; also scored by SSL Labs)
• Keep TLS 1.2 with strong ciphers as a fallback (don’t disable it unless all your visitors use modern browsers)
• Have HSTS enabled (add_header Strict-Transport-Security "max-age=31536000; includeSubDomains")
• Use ECDSA or RSA-2048+ certificates from a trusted CA

Check out our TLS configuration guide for achieving A+ on SSL Labs for the full setup. Combined with openssl-nginx 4.0, you’ll be secure for both today’s attackers and tomorrow’s quantum computers.

Performance: Does PQC Slow Things Down?

Great question, and the answer is: barely. ML-KEM was designed to be fast. The main cost is slightly larger key exchange messages — about 1KB extra in the TLS handshake. That’s one extra small packet. On modern networks, it’s imperceptible.

Once the handshake is done, your data is encrypted with AES-256-GCM as usual — PQC doesn’t touch the bulk encryption performance at all. Throughput, latency, requests-per-second — all unchanged. And with openssl-nginx’s kTLS support, your handshake is even faster because TLS crypto is offloaded to the kernel.

Migration Checklist: From Classic TLS to Quantum-Safe

1. Install openssl-nginx 4.0 from deb.myguard.nl — this gives you ML-KEM support
2. Update NGINX or Angie to the latest version from our repository
3. Verify TLS 1.3 is enabled in your nginx.conf (ssl_protocols TLSv1.3; or TLSv1.2 TLSv1.3)
4. Optionally add ssl_ecdh_curve with X25519MLKEM768 as first preference
5. Reload NGINX: nginx -s reload
6. Test: run openssl s_client and look for X25519MLKEM768 in the negotiated group
7. Check SSL Labs: run a test at ssllabs.com to confirm your score hasn’t dropped

Frequently Asked Questions

Do quantum computers exist yet?
Yes — small ones do. IBM, Google, and others have quantum processors with dozens to hundreds of qubits. But breaking RSA-2048 would require millions of stable qubits. We’re not there yet. Estimates range from 10–20 years. But “Harvest Now, Decrypt Later” attacks mean you should start protecting sensitive traffic today.

If quantum computers don’t exist yet, why bother now?
Two reasons: (1) Harvest Now, Decrypt Later — adversaries are recording your encrypted traffic now. (2) Infrastructure change takes years. Starting now means you’re ready before the threat arrives, not scrambling when it does.

Does enabling hybrid TLS break anything?
No. Hybrid TLS is fully backward-compatible. Clients that don’t support ML-KEM fall back to X25519 automatically. Nobody gets disconnected. You just get stronger security for modern clients while keeping compatibility for old ones.

Does Google Chrome already use post-quantum TLS?
Yes! Chrome has been sending X25519MLKEM768 key shares since 2024. If your server supports it (via OpenSSL 3.5+), Chrome automatically negotiates the hybrid cipher. Check your SSL access logs — you might already be doing PQC.

What’s the difference between ML-KEM and Kyber?
Same thing, different name. CRYSTALS-Kyber was the original research name. After NIST standardized it, the official name became ML-KEM (FIPS 203). OpenSSL uses ML-KEM in its API. Some docs still say Kyber — don’t panic, it’s the same algorithm.

Will Let’s Encrypt support post-quantum certificates?
They’re working on it. Let’s Encrypt has announced plans to support post-quantum signatures. For now, X25519MLKEM768 key exchange (already available) protects the bulk of the risk. Post-quantum certificate signing will follow.

How do I know if my NGINX is using PQC right now?
Run: openssl s_client -connect yourdomain.com:443 -tls1_3 2>&1 | grep "Server Temp Key". If you see X25519MLKEM768 in the output, you’re using hybrid post-quantum TLS. If you see just X25519, you’re on classical only.

Is post-quantum cryptography the same as quantum encryption?
No — completely different things. Quantum encryption (QKD — Quantum Key Distribution) uses actual quantum physics hardware and fiber optics to exchange keys. It’s very expensive and impractical for the internet. Post-quantum cryptography is classical software running on normal hardware, designed to be resistant to quantum attacks. PQC is what you can actually deploy on your server today.

Related Posts

• openssl-nginx: A Dedicated OpenSSL Build for NGINX and Angie — the OpenSSL package that makes PQC possible in your NGINX
• OpenSSL 4.0 for NGINX: Upgrading openssl-nginx from 3.x to 4.0 — what changed and why it matters for post-quantum support
• TLS Configuration and Achieving A+ on SSL Labs — full TLS hardening guide to pair with PQC
• The Enigma Machine: How Nazi Germany’s “Unbreakable” Code Got Demolished — a reminder that “unbreakable” is only unbreakable until it isn’t
• Angie vs NGINX: Complete Comparison — which web server to run your quantum-safe TLS on