I ran one openssl command and found my blog was already post-quantum
I did not set out to make this blog quantum-resistant. I've never configured a cipher suite on it, never touched a curve preference. But this week I ran one openssl command against my own server out of curiosity, and there it was: my little Drupal blog is already doing hybrid post-quantum key exchange, by default, because the software underneath quietly switched it on. It's a small, cheerful example of the internet getting more secure without anyone having to care.
The one command
If you have OpenSSL 3.5 or newer, you can check any site:
echo | openssl s_client -connect blog.bms.ovh:443 -servername blog.bms.ovh 2>/dev/null \
| grep -i "Negotiated TLS1.3 group"Here's what my box actually printed:
Negotiated TLS1.3 group: X25519MLKEM768The exact same group cloudflare.com negotiates. I didn't do anything to earn it.
What X25519MLKEM768 is
It's a hybrid key exchange. It runs the classical X25519 elliptic-curve exchange we've used for years, and alongside it ML-KEM-768 — the NIST-standardised post-quantum key encapsulation mechanism (the FIPS 203 successor to Kyber). The session key is derived from both, so it stays secure as long as either half is unbroken. That means it can't be weaker than what we had, and it adds resistance to a future quantum computer. Belt and braces, on by default.
Why it showed up without me doing anything
Traefik, which terminates TLS at the edge of my Coolify setup, is written in Go. And since Go 1.24, the standard library enables X25519MLKEM768 by default, for both clients and servers, whenever the TLS config doesn't pin its own curve list. Traefik doesn't override it, so a Traefik binary built with a recent Go toolchain just... speaks post-quantum. Chrome has defaulted to it since late 2024. Per Cloudflare's Radar, roughly half of human HTTPS traffic to them is already post-quantum, up from about 2% at the start of 2024. This happened fast, and mostly invisibly.
The best security upgrades are the ones you never install. This one arrived as a side effect of keeping my software reasonably current.
The honest caveat
"Free" comes with fine print worth stating plainly, because I don't want anyone cargo-culting a false guarantee:
- It depends on the Go version your proxy was compiled with. A Traefik (or any Go server) built against a pre-1.24 toolchain won't offer it, whatever the app version says. My check passing is the proof; assuming isn't.
- If you explicitly set
curvePreferencesin Traefik's TLS options and leave the hybrid group out, you silently turn it off. A well-meaning "hardened" TLS config can disable the newest protection. Verify, don't assume. - It's the key exchange group, distinct from ECH (which hides the SNI) and from your TLS version or cipher. Different knobs, different problems.
So does it matter for a blog?
Honestly? For this blog, almost not at all, and I'd rather say that than oversell it. The threat it defends against is "harvest now, decrypt later": an adversary records your encrypted traffic today and decrypts it years from now once a quantum computer exists. That's a real concern for banking sessions, health records, anything with long-lived confidentiality that's private in transit. My blog serves public posts to anonymous readers. There's no secret payload to harvest. The post-quantum handshake is protecting a conversation that has nothing to hide.
And yet I like that it's there. It costs nothing, it can't hurt, and it means the day someone does host something sensitive on the same stack, the protection is already the default rather than a migration project. That's the quiet win: secure-by-default is spreading through the ecosystem, so the boring act of keeping your software current now hands you future-proofing you never asked for. Run the command on your own site. There's a decent chance you're already living in the post-quantum era and didn't know it.