The Quantum Apocalypse

I run a WordPress site out of a DigitalOcean droplet. Ubuntu 24.04, Apache, the usual furniture. Nothing fancy. And a few days ago I decided I wanted post-quantum cryptography key exchange on it, because an SSL Labs scan flagged its absence in amber, and amber colours have a way of nagging at you.

So I went looking. Turns out the answer was no, and it took a surprising amount of digging to arrive at a no I actually trusted.

What is PQC Key Exchange? The short version: current TLS key exchange relies on classical algorithms like ECDHE. A sufficiently powerful quantum computer could, in theory, break those one day. The practical worry isn’t someone reading my traffic tomorrow — it’s “harvest now, decrypt later.” Someone captures the encrypted traffic today, sits on it, and decrypts it once the hardware catches up. For a WordPress blog with Fediverse integration, that’s a fairly theoretical threat. Still, I wanted to know if I could close the gap, even if I decided not to bother.

The first pass through this — with an AI assistant, for full disclosure — got waved off as low priority, something that would “probably land via a point release.” That was lazy. Not wrong in spirit, but wrong in the specific way that matters: it treated an inference as a fact. I pushed back, because I’d rather have an honest “I don’t know yet” than a confident guess dressed up as knowledge.

What followed was a proper dig, one verifiable fact at a time.

• Ubuntu 24.04 ships OpenSSL 3.0.13. Confirmed, not inferred — checked against Launchpad’s own changelog, which tracks every patch back to a named CVE.
• OpenSSL doesn’t get native PQC key exchange until version 3.5. That’s confirmed too, cross-checked against an external source unconnected to this whole exercise.
• Ubuntu doesn’t ship 3.5 until the 26.04 release. So no point release rescues me here. The only route to a newer OpenSSL through Ubuntu’s own repositories is a full OS upgrade, and even backports — which exist as a mechanism in principle — don’t carry it.

There’s a project called oqs-provider that bolts post-quantum algorithms onto an existing OpenSSL 3.x installation. It would technically install against my 3.0.13. But its own documentation admits incomplete TLS 1.3 support at that version, plus a crash bug only confirmed fixed from 3.0.14 onwards — one patch release above what I’ve got.

Whether Ubuntu’s security patches happen to include an unlisted fix for that bug anyway, nobody can say for certain. No CVE was ever assigned to it, so there’s no paper trail to check. And nobody seems to have actually run oqs-provider under Apache’s mod_ssl in a real production environment and written about it. Every example I found used Nginx, or a bare command-line test that shuts down before any of the awkward long-running-process problems would show up.

Where does that leave me? Nowhere, for now — and that’s fine. I’m not modifying a live production server on the strength of a plausible theory and an absent field report. If I want to try PQC key exchange, the honest path is a disposable droplet running a separate proxy built against a newer OpenSSL, tested well away from anything that actually serves traffic.

For a personal blog, “harvest now, decrypt later” isn’t pressing enough to justify that risk today. I’ll revisit it properly when Ubuntu 26.04 becomes my upgrade target, and the amber warning can keep nagging until then.