{"id":30921,"date":"2025-09-03T06:02:45","date_gmt":"2025-09-03T10:02:45","guid":{"rendered":"https:\/\/www.lpi.org\/articles\/\/"},"modified":"2025-09-03T06:13:18","modified_gmt":"2025-09-03T10:13:18","slug":"tls-post-quantum-and-everything-in-between-at-lfnw25","status":"publish","type":"post","link":"https:\/\/www.lpi.org\/zh-hant\/blog\/2025\/09\/03\/tls-post-quantum-and-everything-in-between-at-lfnw25\/","title":{"rendered":"TLS, Post-Quantum, and Everything In Between at LFNW25"},"content":{"rendered":"

Some talks start as slides. Others start as hallway conversations, scan results, certificate errors, and someone in the team asking: \u201cHey Ted, do we really need TLS 1.3?\u201d By the time I finished preparing this talk for LinuxFest Northwest 2025 \u2014 in what was also the 25th anniversary of both LFNW and LPI \u2014 it was clear we needed a post on security in the quantum computing age that would reach beyond the room.<\/p>\n

My quest isn\u2019t just about standards. It\u2019s about making sure that the web we build \u2014 especially in FOSS \u2014 is one step ahead of what\u2019s coming. Even when what\u2019s coming is\u2026 quantum.<\/p>\n

As I was at LFNW (see full report here), I was happy and proud to give the talk \u201cSecuring Your Web Server with Post-Quantum Cryptography.\u201d This blog post is a rethinking of that session, adapted to this medium, and maybe a bit easier to search and share.
\nLet\u2019s dig in.<\/p>\n

SSL, TLS, and That Whole Mess<\/h2>\n

Yes, we still call them SSL certs. But SSL has been deprecated for almost 30 years.
\nToday, if your setup isn\u2019t using TLS 1.2<\/a> at a minimum (or hopefully TLS 1.3<\/a>) you\u2019re already in trouble.<\/p>\n

TLS 1.3 isn\u2019t just cleaner \u2014 it removes old baggage (like RSA key exchanges, which lack the forward secrecy in Diffie-Hellman), enforces better cipher suites, and lays the groundwork for post-quantum support<\/em>. TLS 1.3 introduces a more efficient handshake between the clients and servers, as shown in Figure 1 (courtesy Cloudflare site):<\/p>\n

\"Figure

Figure 1 Difference between opening handshake in TLS 1.2 and TLS 1.3.<\/p><\/div>\n

Because that\u2019s where we\u2019re going. Fast. Every time I read about a new breakthrough against RSA with quantum computers, the attacks are against larger and larger numbers. And the actual situation may be even worse than the reports, because the published reports and studies we get don\u2019t include state actors or those wishing to not publicly disclose their achievements.<\/p>\n

I certainly don\u2019t know on what date our widely used RSA 2048-bit will be broken. But many feel that NIST\u2019s recommendation to deprecate RSA and ECDSA by 2030, and disallowing them after 2035, is reasonable, given the release of open source tools such as OpenSSL 3.5 that allow sites to migrate off of many of today\u2019s quantum-vulnerable ciphers.<\/p>\n

These tables show the timelines for migrating away from vulnerable standards:<\/p>\n

\"Current

Current known Quantum-vulnerable algorithms<\/p><\/div>\n

\"Current

Current known Quantum-vulnerable key-est. schemes<\/p><\/div>\n

NIST has been working with cryptographic researchers around the globe for almost 10 years to finalize drafts for new quantum-resistant ciphers, and in many cases backups, in case unnoticed vulnerabilities turn up in the initial choices.<\/p>\n

What We Mean by “Post-Quantum”<\/h2>\n

Post-quantum cryptography (PQC) isn\u2019t a buzzword. It\u2019s a practical response to a looming issue: what happens to our encrypted traffic when quantum computers hit scale?
\nYou don\u2019t need to guess. Attackers are going to harvest now, decrypt later<\/em>.<\/p>\n

Which is why I focused the second half of my session on Module Lattice-based Key Encapsulation Mechanism (ML-KEM)<\/a>, Module-Lattice-Based Digital Signature Algorithm (ML-DSA),<\/a> and HQC<\/a>: algorithms vetted by NIST and already partially deployed in hybrid mode by Cloudflare, Google, and other cloud vendors.<\/p>\n

If your current server setups support OpenSSL 3.5<\/a>, you\u2019re already in a good place. If not, you have work to do, and should begin planning and testing now.<\/p>\n

Figure 2 shows the trajectory for OpenSSL.<\/p>\n

\"Figure

Figure 2. OpenSSL LTS versions (longer bars, light blue), will be supported for 5 years<\/p><\/div>\n

If your work doesn\u2019t involve configuration or securing of web servers or API endpoints using TLS, you may not need to implement OpenSSL 3.5 to benefit from post-quantum security. The latest versions of Firefox, Chrome, and likely other widely used browsers currently have built in support for the ML-KEM PQC algorithm when connecting to a server or TLS endpoint using ML-KEM.<\/p>\n

Several browsers are already utilizing PQC in a hybrid fashion, meaning that the Certificate will still be validated with tools designed before the quantum threat, yet are still known to be quantum-resistant and utilize the PQC encryption if both server and browser clients support it. Cloudflare estimates that currently 2% of their traffic is PQC-resistant on their network. Major computing centers such as Google have been utilizing PQC on their internal networks since 2022.<\/p>\n

The new set of post-quantum algorithms have been designated FIPS ID numbers for tracking in compliance audits where data requires use of these new algorithms. These numbers are listed in Table 3.<\/p>\n

\"Key

Key OpenSSL 3.5 PQ supported algorithms<\/p><\/div>\n

IANA and the OpenSSL organization are setting the naming conventions of new PQ algorithms similar to the naming conventions for cipher suites used in the past.<\/p>\n

Certificates: DV, OV, EV \u2014 and Expiry Math<\/h2>\n

Trust and Privacy on the internet involves not just technical methods, but social trust methods. SSL Certificates used for websites, TLS endpoints, and code signing use two methods, and Certificate Authorities (CAs) provide for 3 different levels of Certificates.<\/p>\n

A lot of us use Let\u2019s Encrypt<\/a>, and that\u2019s perfectly fine for most sites. But it\u2019s worth knowing that the Domain Validation (DV)<\/a> certificates offered by Let’s Encrypt are basic \u2014 good just for personal projects and internal tools. Organizational Validation (OV) and Extended Validation (EV) certificates are recommended for banks, public services, and anywhere with identity needs beyond DNS.<\/p>\n

Also: even a 10-year cert purchase needs to be reissued every 13 months. That\u2019s the way the ecosystem handles expiry and trust. Our Internet trust is based on both technical standards and social trusts, and Certificates that are OV and EV, whether used for websites or code signing purposes, go through more stringent auditing than DV certificates.<\/p>\n

If you don\u2019t know what your certs are doing, I highly recommend SSL Labs<\/a>, SSLScan<\/a>, and similar command-line tools.<\/p>\n

Compliance: PCI, HIPAA, FIPS \u2014 and the Real Costs<\/h2>\n

If you\u2019re working in healthcare, fintech, or gov contracts, compliance isn\u2019t optional.<\/p>\n

I broke down in the talk how FIPS 140-2<\/a> \/ 140-3<\/a>, FedRAMP<\/a>, and other standard frameworks define cryptographic validity \u2014 and how much it can cost to certify a distro or product.<\/p>\n

Here\u2019s the short version: millions<\/em>. Over time, but still.<\/p>\n

That\u2019s why most people opt for validated modules from Red Hat, Rocky, SUSE, Alma, Ubuntu, etc. You still get enterprise support, and someone else takes care of the certification treadmill (and extensive fees).<\/p>\n

Backward Compatibility (and Grandma\u2019s Browser)<\/h2>\n

Why not just move to TLS 1.3 and forget 1.2?<\/p>\n

Because real users don\u2019t all run the latest OS. Maybe it\u2019s an Android 5 phone. Maybe it\u2019s a kiosk on Windows 7. Maybe it\u2019s your grandma\u2019s iMac that still works.<\/p>\n

Supporting both TLS 1.2 and 1.3, with smart cipher selection, keeps things secure and usable.<\/p>\n

Elliptic Curve cryptography (ECC) helps here too \u2014 it\u2019s lighter on CPU and faster on mobile devices than the classic RSA algorithm, especially when extending RSA to 4096 bits. Over half of the traffic on the internet is from mobile devices, so algorithms\u2019 CPU loads are of great concern for both global energy usage and the battery life of portable devices.<\/p>\n

Ready to Upgrade?<\/h2>\n

I shared this checklist live. It\u2019s a good summary:<\/p>\n