The term on this page
- TLSTransport Layer Security
- the protocol behind the padlock in your browser
What is new
The observatory measured one thing: does a server negotiate post-quantum key exchange. It now also measures whether that server offers TLS session resumption, whether it offers it unprompted, and whether it honours its own ticket. First reading on the web panel: 69 of 70 issue a ticket, 40 of 70 volunteer one, 61 of 69 resume.
Post-quantum key exchange is close to done. On our panel it is the majority position and has been for months. Post-quantum authentication has not started, and the reason is size: an ML-DSA certificate chain runs to roughly 18 kB where an elliptic-curve one runs to about 3.5 kB, which does not fit in the ten packets a server may send before it has to wait for the client.
That makes one existing mechanism far more valuable than it used to be. A resumed TLS connection sends no certificate at all. Classically, resuming saves about 3.5 kB and nobody agonises over it. With post-quantum certificates it saves roughly 18 kB and a round trip, which is the difference between a fast connection and a slow one on every mobile network in the world.
So resumption stops being an optimisation and becomes the thing that decides whether post-quantum authentication is affordable. If we are going to measure whether the web is ready, we have to measure whether the web still offers it. Nobody was publishing that, so we started.
Three questions, three different denominators
The page shows three counts rather than three percentages, and each one sits above the population it was actually drawn from. That is not pedantry. The three questions reach three different sets of hosts, and averaging them would produce a number that means nothing.
- Issues a ticket. Every reachable host is asked. A ticket is what a client offers back to resume, so a host that issues none is not offering resumption at all.
- Without being asked. Also every reachable host, measured on a connection that sends nothing whatsoever.
- Resumes when offered. Only the hosts that issued a ticket. A host that never issued one was never offered one back, so it cannot be said to have refused.
Null is not no
In the database and on the page, a host that was never asked a question records null, never false. A host that issued no ticket has resumed = null, not resumed = false, because nothing was ever offered to it. Recording a coverage gap as a refusal is the easiest way to manufacture a finding that is not there, and it is the mistake we most wanted to make impossible.
The measurement that forced the design
The obvious way to measure ticket issuance is to open a TLS connection, wait, and see whether a NewSessionTicket arrives. We built that, and it was wrong. Many servers send nothing until a request arrives.
We tested it directly: the same harness, the same fourteen-host panel, run twice back to back, differing in one argument.
| Connection | Hosts issuing a ticket |
|---|---|
| Silent, no request sent | 8 of 14 |
| One HEAD request | 14 of 14 |
The six that withhold until asked are every Google-fronted and every Cloudflare-fronted name on that panel and nothing else: cloud.google.com, google.com, mozilla.org, www.cloudflare.com, developers.cloudflare.com and ietf.org. Neither mozilla.org nor ietf.org is a cloud provider. They land in that group by whose edge terminates their TLS, which is the point: this is a property of the terminating stack, not of the site.
So the probe now sends one HEAD request, and only to the hosts that volunteered nothing. Measuring without it would have reported no resumption for a large share of the web, which is false. It also makes our figures comparable to the only internet-scale measurement of this, Hebrok et al. at USENIX Security 2025, who found 94.8% of reachable TLS domains issuing a ticket, 1,108,322 of 1,169,527, and who also probed by sending an HTTP request. Before this experiment that agreement was an accident of how our harness happened to be written.
What a refusal looks like, and what it does not
Eight hosts on the web panel today issued a ticket and then completed a full handshake when that ticket was offered back. That is the interesting case: the server is advertising resumption and then declining it.
One of those readings is solid and the rest are not, yet. github.com has now refused in every run we have made, on two days and across two independent implementations of the probe, always at the same address and with a ticket lifetime hint that never moves. The others are mostly CDN-fronted names, where a single address can front many machines. We watched aws.amazon.com resume at one address and refuse at another ninety seconds later. A single refusal from an anycast address is not evidence of a policy, and we would rather say so than publish a number that looks sharper than it is.
This is why the daily series matters more than any single day. A refusal that repeats is a policy. A refusal that appears once is weather.
What we will not do
A session ticket is only ever offered back to the host that issued it, at the same address and under the same server name. Replaying a ticket at a host that did not mint it is the genuinely interesting experiment in this area, and it is the one that produced CVE-2025-23419. It is also, against infrastructure we do not own, an attempt to reach one configuration with credentials minted by another. That is probing someone else's access control, and we have no standing to do it. The restriction is enforced in code rather than promised in prose.
We also send no credentials of any kind, we read no response body, and we honour removal requests within one measurement cycle. The full policy is in the methodology and in the open-source pqc-observatory repository.
A correction, on the day
Pinning the resolved address, which the resumption measurement needs so that a failure to resume cannot be confused with landing on a different edge node, introduced a bug: IPv6 addresses were not bracketed, and OpenSSL rejects an unbracketed IPv6 address outright. On the morning run of 28 August, 95 hosts whose DNS answered with an AAAA record were recorded as unreachable when they were nothing of the sort. It was found, fixed and the day re-probed within hours, and the panel is back to 255 reachable. We mention it because the value of a daily series is that you can check it, and anyone who pulled that morning's data deserves to know why it looked odd.
Where to look
The three counts are on the observatory alongside the hybrid key-exchange figure, and every host in the panel now carries its own ticket and resumes columns. The method, including what the numbers deliberately do not mean, is on the methodology page.
The number we expect to matter most over time is the third one. Resumption under mutual TLS is already off at several large front doors, disabled in response to a class of vulnerability that the TLS specification does not tell servers how to avoid. Those operators chose the safe answer available to them. Post-quantum is about to make that answer very expensive, and a public daily measurement is how anyone will notice which way it goes.