What this can see,
and what it cannot.

Every report ends with what that particular scan could not settle. This page holds the other kind: the limits of the instrument itself, which are the same for every scan and say nothing about any server. They used to be printed on every report, where a reader had no way to tell them apart from a finding about their own host.

How to read a report

A report says four kinds of thing, and telling them apart is most of knowing what it means.

Findings are graded. Each one names a rule, states what was measured, and cites the document it rests on. Grading is worst-case: one insecure option makes a configuration insecure however many strong options sit beside it, because an attacker chooses which to negotiate.

Observed is what the scan established and deliberately does not grade — a post-quantum key exchange the server accepted, a stapled revocation response that verified, how many names one key stands behind. These are results. A verdict is withheld where no document this rule set follows requires one, because a verdict invented here would be this project grading against its own opinion.

Not established for this host is what this scan could not settle, for a reason that lies with the server in front of it: it stopped answering before the suite list ran out, it offers only one protocol version, it sent a field that could not be parsed. These qualify that report's verdict and travel with it.

Limits of this method are below. They are true of every scan, so they are stated once, here, rather than repeated under a heading that made each report look like a failure.

The distinction that matters most: strong is the verdict that claims an absence, and an absence can only be claimed from a complete measurement. Where a list was cut short the verdict is ungraded rather than strong, and the command line exits 4 for it rather than 0.

Obsolete suites, asked for directly

The list of accepted cipher suites is built by offering suites one at a time, through the TLS library this program is written with, Go's. That library leaves the obsolete families out on purpose, so it cannot offer them, and a server that still accepted one would never appear in the list. So each family is asked about on its own, with a hello this program writes byte by byte, offering every suite in the family at once. Refused means the server accepted none of them; accepted names the suite it chose, and grades it like any other. Because the whole family is offered in one hello, an acceptance shows that one of them is accepted, not every one.

Export-grade

Suites weakened in the 1990s to 40- and 56-bit keys to satisfy export rules. Breakable today, and the root of attacks such as FREAK and Logjam.

NULL, no encryption

Suites that authenticate the server but do not encrypt: everything after the handshake travels in the clear.

Finite-field DHE

Key exchange over classic Diffie-Hellman groups rather than elliptic curves. RFC 10015 prohibits offering or selecting these suites in TLS 1.2; the groups are often weak or shared.

Anonymous, no certificate

Suites in which the server presents no certificate, so anyone on the path can pose as it.

Downgrade signal

A hello that claims an older version and carries TLS_FALLBACK_SCSV, the mark RFC 7507 defines for a client retrying lower. A server that speaks something newer should refuse it, which stops a connection being pushed down to an older version. Honoured means it was refused. Reported, not graded: the version it would land on is graded in the version table.

SSL 3.0 is asked for the same way, and is a protocol version rather than a family of suites, so it appears in the version table.

Only the first hop was measured

Everything here describes the endpoint that answered on the address named at the top of this report. Where a content delivery network, a reverse proxy or a load balancer terminates TLS, that endpoint is the one measured: the link from it to the server behind it is not visible from here, and may negotiate other versions, other suites and another key exchange. A name that resolves to several addresses was measured at one of them; each of the others is asked a single handshake, which shows what a client is given there and not everything that machine would accept.

Only the suites this client can offer were offered

Cipher suites were enumerated only among those Go's TLS stack implements. SSL 3.0 and the export-grade, NULL, finite-field DHE and anonymous suites were asked about with a hand-written hello, which establishes whether any of each is accepted and not every one that is. Other suites outside Go's stack, and SSLv2, are not covered. A server that speaks a version but shares no suite with this client answers a handshake the same way as one that refuses the version, so a refusal here is not proof the version is switched off.

TLS 1.3 suites are asked from the registry

TLS 1.3 suites are asked one at a time with a hand-written hello offering each suite in the IANA registry, because Go gives a client no way to choose among them. A suite outside the registry is not asked about, and where that hello is not answered the way this scan's own handshake was, only the negotiated suite is listed and the report says so.

The verdict rests on one root store

A chain reported as trusted was verified against one root store, and the verdict rests on that store: on Linux and other unix systems, the store of the machine that ran this scan; on Windows and macOS, the copy of Microsoft's or Apple's store this build carries, because the platform's own verifier fetches what a scanned certificate names. Where the report names them, what Mozilla, Chrome, Microsoft and Apple make of the chain comes from copies of their stores dated in the report: a store changes after that date, and only which roots it includes and Mozilla's dates for distrusting a root are evaluated — other conditions a store places on a root are named, not applied.

No authority is asked about this certificate

No certificate authority is asked whether this particular certificate is still valid. That question carries the certificate's serial number, so it would tell the authority which certificate somebody is looking at, and no build asks it. Revocation is not therefore unexamined: a status response the server stapled into the handshake is read, because reading bytes already in hand asks nobody anything, and where a certificate names a revocation list an installation somebody runs themselves fetches it — one list covers thousands of certificates, so the request names none of them. The demonstration fetches no list, and that call is compiled out of its build rather than switched off. Where neither a staple nor a list settled it, a chain reported as trusted reaches a root and is in date, and may still have been withdrawn.

Transparency receipts are checked against one browser's log list

A receipt is checked against the key Chrome's log list gives its log, as that list stood on the date the report names. A receipt from a log the list does not name has no key to be checked against, and nothing here decides how many receipts, or from which logs, a particular browser requires.

What else is written down

Every property this project holds itself to is in docs/invariants.md, each one naming the test that guards it and, where there was one, the mistake that produced it. What changed between rule sets is in docs/policy-changes.md, because a report graded under one version is not comparable with a report graded under another.

What a scan sends to a server, what is recorded about it here, and how to have a domain excluded are on the privacy page.