TLS 1.3, 1.2, and post-quantum ranking changes

2026-05-18T21:51:26-07:00

tl;dr: How’s My SSL?’s ranking of clients using TLS 1.2 and of clients using TLS 1.3 without post-quantum key agreement will be changing. A small change a month from now, and a bigger one in 6 months.

On 2026-06-14 (a month from now), How’s My SSL?’s API will begin marking TLS 1.2 connections as “Improvable”. Also on that date, How’s My SSL?’s API will begin marking TLS 1.3 connections that do not support post-quantum key agreement as “Improvable”.

On 2026-12-14 (6 months from then), How’s My SSL?’s API will begin marking TLS 1.2 connections as “Bad”. Also on that date, How’s My SSL?’s API will begin marking TLS 1.3 connections that do not support post-quantum key agreement as “Bad”. (Note: only TLS 1.3 has named groups that provide post-quantum key agreement).

So, why is this happening?

TLS 1.3 is the new minimum for secure web clients. One reason we can give is an appeal to authority: TLS 1.3 has been the default in browsers for 8 years and modern web clients have supported it for a while. TLS 1.3 is even required in HTTP/3 as QUIC builds it in.

But there are real rationales.

TLS 1.3 has advanced the security of its users significantly over TLS 1.2 while also being faster than TLS 1.2.

TLS 1.3 has forward secrecy by default. This prevents passive attacks where a bad guy scoops up traffic now and decrypts it later using newer algorithmic attacks or by just gaining access to a previously private key from a service provider.

TLS 1.3 also improves the security of session resumption. It does so by unifying the different resumption mechanisms into one, removing overcomplications in the resumption state machine, and improving the design of session tickets.

In TLS 1.2, adding forward secrecy meant implementing truly gnarly session resumption architectures to keep user requests fast and prevent some subtle security problems that resumption could introduce. Read We Need To Talk About Session Tickets for some details on the specifics of session tickets.

(Howsmyssl.com was built, in fact, because of these passive “harvest now, decrypt later” attacks and the paucity of information about how clients supported forward secrecy and session resumption. A colleague and I were working at Twitter during the Snowden revelations in 2013. Those described how the NSA was scooping up as much web traffic as possible to decrypt later. And if the NSA was doing that, others were or also would soon. We wanted to know more about what our web clients could do and getting that data from our existing stacks was non-trivial. So, I built this small tool to tell us what the clients could do, pointed our clients at it, and we made decisions from there.)

TLS 1.3 also has post-quantum key agreement and will soon have pure post-quantum key agreement encryption. The former is deployed in modern web browsers and the latter will be Real Soon Now. Unfortunately, not all web clients are as on-it as the browsers. But those clients should be. Recent developments in quantum computation research have accelerated the timeline for migrating to post-quantum encryption. The sooner we migrate to it, the less data a quantum “harvest now, decrypt later” event can affect. Those developments have caused both Google and Cloudflare to set a date of 2029 to complete their migration to post-quantum cryptography across not just TLS, but their entire suite of encryption mechanisms (see Quantum frontiers may be closer than they appear, and Cloudflare targets 2029 for full post-quantum security).

TLS 1.3 includes some version and cipher-suite downgrade preventions from on-path attacks. TLS_FALLBACK_SCSV and similar techniques had previously addressed those issues somewhat, but not all systems implemented them well or at all. Having those tools baked into the protocol itself means we don’t have to worry for our users.

And all of that happens while TLS 1.3 is still faster than previous protocols, in part, because it implements 0-RTT for session resumption. Prior versions of TLS had lots of chatter back and forth between the client and server that got removed in TLS 1.3. No more round trips between the machines means better experiences for everyone.

Outro

TLS 1.3 is the new best choice for secure web traffic and has been for some time. And the time to start the post-quantum mitigations are now. How’s My SSL? is going to reflect that.

This was also announced on the howsmyssl-upkeep mailing list.

Post-quantum detection added

2026-05-18T19:58:47-07:00

How’s My SSL? can now detect if an HTTPS client supports post-quantum key agreement. You can find a description of post-quantum key agreement and its purpose on the Post-Quantum Key Agreement section on the about page.

While the top-level client ranking is currently unchanged, the Post-Quantum Key Agreement section on the main page of https://www.howsmyssl.com will show a small Improvable button to clients lacking support for post-quantum key agreement.

The /a/check API now has two new fields:

post_quantum_key_agreement - a boolean reporting whether the TLS client supports one of the named groups that provide post-quantum key agreement
given_named_groups - a list of strings describing which named group IDs (formerly called curve IDs in TLS 1.2) were included in the client hello

We plan to change the ranking of clients that don’t support cipher suites with post-quantum key agreement, but that’ll be discussed in a follow-up.

This has also been posted on the howsmyssl-upkeep mailing list.

The How's My SSL? Blog

TLS 1.3, 1.2, and post-quantum ranking changes

So, why is this happening?

Outro

Post-quantum detection added