TLS certificates were (almost) never particularly well verified

September 21, 2024

Recently there was a little commotion in the TLS world, as discussed in We Spent $20 To Achieve RCE And Accidentally Became The Admins Of .MOBI. As part of this adventure, the authors of the article discovered that some TLS certificate authorities were using WHOIS information to validate who controlled a domain (so if you could take over a WHOIS server for a TLD, you could direct domain validation to wherever you wanted). This then got some people to realize that TLS Certificate Authorities were not actually doing very much to verify who owned and controlled a domain. I'm sure that there were also some people who yearned for a hypothetical old days when Certificate Authorities actually did that, as opposed to the modern days when they don't.

I'm afraid I have bad news for anyone with this yearning. Certificate Authorities have never done a particularly strong job of verifying who was asking for a TLS (then SSL) certificate. I will go further and be more controversial; we don't want them to be thorough about identity verification for TLS certificates.

There are a number of problems with identity verification in theory and in practice, but one of them is that it's expensive, and the more thorough and careful the identity verification, the more expensive it is. No Certificate Authority is in a position to absorb this expense, so a world where TLS certificates are carefully verified is also a world where they are expensive. It's also probably a world where they're difficult or impossible to obtain from a Certificate Authority that's not in your country, because the difficulty of identity verification goes up significantly in that case.

(One reason that thorough and careful verification is expensive is that it takes significant time from experienced, alert humans, and that time is not cheap.)

This isn't the world that we had even before Let's Encrypt created the ACME protocol for automated domain verifications. The pre-LE world might have started out with quite expensive TLS certificates, but it shifted fairly rapidly to ones that cost only $100 US or less, which is a price that doesn't cover very much human verification effort. And in that world, with minimal human involvement, WHOIS information is probably one of the better ways of doing such verification.

(Such a world was also one without a lot of top level domains, and most of the TLDs were country code TLDs. The turnover in WHOIS servers was probably a lot smaller back then.)

PS: The good news is that using WHOIS information for domain verification is probably on the way out, although how soon this will happen is an open question.


Comments on this page:

This still exists: https://en.wikipedia.org/wiki/Extended_Validation_Certificate

Though modern browsers don't show EV certificate indications prominently like they used to, so I doubt many folks use them anymore. They're also pretty incompatible with frequent certificate rotation.

I think it’s important to make a clear distinction between verifying identity and verifying ownership.

We learned from the failures of EV certificates that there’s no benefit from linking a certificate to a real-world identity, because the people relying on the certificate have no way to link the real world identity to security properties that matter.

What is actually important is verifying that the person requesting the certificate is also the person in control of the domain names it covers. That way the certificate meaningfully links a URL to its server.

Whois could in principle be a reasonable way to verify domain ownership, except that its data is often redacted by privacy services, it uses insecure transports, and (wrt the recent spectacular exploit) many whois clients (eg Debian’s) use the wrong algorithm to locate whois servers. (The right algorithm is to follow referrals that match the delegation hierarchy, like FreeBSD https://cgit.freebsd.org/src/commit/usr.bin/whois/whois.c?id=6f4d88df9f3f272c006118386a158bb2bf5a3c08)

By vowhite at 2024-09-22 12:07:09:

TLS Certificate Authorities were not actually doing very much to verify who owned and controlled a domain.

"Who" implies a person. Even if that were verified by a certificate authority, there's basically nothing useful that client software would be able to do with it. So, the situation you're talking about was much worse: they weren't even properly handling the more mechanical aspects, like which DNS server is associated with a domain (which is trivially obtained via DNS itself, e.g., "host -t NS com."). This is them being incompetent, not them deciding against thorough verification for practical reasons. Also note that whois records generally have no security, unlike the NS records which are now almost always signed by the registry; they could've grabbed both and checked that they match (probably still could with Google's proposal; it depends of the definition of "rely on"), but they decided to only grab the insecure one. A TXT or RP record within the domain could specify a contact person, though I don't see why that's needed if DNS control is proven.

One thing the authorities should be doing, and last I checked were not required to do, is using DNSSEC during verification, and storing all relevant query data. For example, if I register example.net and don't enable DNSSEC, the signed delegation records from the .net registry will indicate the lack of DNSSEC on this subdomain. The full response set relating to the CAA record (or lack thereof) should be stored forever, and maybe published.

Companies sometimes acquire special-purpose domains like this dotmobiregistry.net—outside their primary domains—and such domains are frequently allowed to expire, often with security impacts. They really need to start treating domain purchases as "forever". With a wholesale cost of about $10/year, retail a bit higher, that's a present value of several hundred dollars if valued as a perpetuity. In other words, the .mobi registry put its users at risk for a one-time savings of less than a thousand dollars, and itself probably spent many thousands cleaning up the mess.

Certificate Authorities have never done a particularly strong job of verifying who was asking for a TLS (then SSL) certificate.

I've long been aware of this, and it's one reason why the WWW encryption is fake.

No Certificate Authority is in a position to absorb this expense, so a world where TLS certificates are carefully verified is also a world where they are expensive.

The pre-LE world might have started out with quite expensive TLS certificates, but it shifted fairly rapidly to ones that cost only $100 US or less, which is a price that doesn't cover very much human verification effort.

I believe $100 to be quite a lot of money for a political middleman who provides nothing of real value.

Written on 21 September 2024.
« Our broad reasons for and approach to mirroring disks
Old (Unix) workstations and servers tended to boot in the same ways »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sat Sep 21 22:32:53 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.