|
Top-level
 But you probably would want to allow only a very small number of CAs to do that. What can you do? For a while, we tried dynamic HTTP Public Key Pinning (HPKP, via the Public-Key-Pins header). But, TOFU issues aside, that was a big footgun, so we deprecated that swiftly. 29 comments
Certificate Transparency (CT) was supposed to make up for (dynamic) HPKP being deprecated, but of course that shifts the defense mechanism from _prevention_ to _detection_. Monitoring CT logs for thousands of domains is a bitch, so ~nobody does that. And DANE... well. For starters it requires DNSSEC, which is like asking for Linux on the Desktop, or generally available IPv6, so... yeah. But sure, let's use the DNS, where we have "Certificate Authority Authorization" or CAA records, specified in RFC8659, and which CAs are required to honor via CA/B Forum Ballot 187 since 2017. CAA records let you specify which CAs you want to authorize to issue certificates for the given domain. This is not perfect: CNAMEs get messy quickly, and you actually have to have your act together and know which domains are used where and how, e.g., with respect to third-parties you CNAME or delegate to. But alright, as so often, it is what it is. Still better than allowing Honest Ahmed and his uncles and cousins to issue certs for your domains. Let's take a look at how widely used CAA records actually are. I looked up CAA records for ~214 million domain names in almost 1,200 TLDs as well as across the Tranco Top 1M Domains list. In total, fewer than 3 million domains have CAA records; fewer than 50K of the Top 1M domains. That's barely 1.4% of all TLDs (4.8% of Top 1M domains) -- not that great, adoption wise. For the domains that _do_ have CAA records set, the most common number of records is small, e.g., four or five CAs authorized to 'issue' and 'issuewild': But over 900 domains have more than 20 CAA records, and a few even more than 50! The 'flags' field should be exactly either 0 or 128: the "Issuer Critical Flag" is bit 0 of the flags field, and not the _value_ of this field. Unsurprisingly, many people get that wrong (with values encountered ranging from 0 to 250, with no clear indication what people might think those values mean): RFC8659 defines three different properties: 'issue', 'issuewild', and 'iodef'. That's it. (CA/B Forum Ballots SC13 and SC14 added 'contactemail' and 'contactphone', but those aren't part of the RFC, and I only encountered 741 and 23 uses of these respectively, so let's ignore them.) Ignoring misspelled records ("issiue", "issuewld", "iodev", ...), here are the CAA records by tag: The 'iodef' property can have one of three methods: mailto, http, and https. Extra l33t points go to kyhwana.org for putting a log4j canary into their CAA record. The most frequently 'iodef' records are shown here. Pretty pleased to see Yahoo's records dominate, since setting the right CAA policy and adding default CAA records for all of Yahoo's (many) parked domains was something I pushed for at my time there. Yay! \o/ But let's see what CAs everybody is authorizing via their 'issue' and 'issuewild' records. In total, I found almost 2,200 distinct 'issue' records (for domains in all TLDs, 456 distinct for the Top 1M domains) and 878 'issuewild' records (all TLDs, 227 Top 1M). Here are the top 20 CAs: But... let's carefully read RFC8659 again. The 'issue' tag grants "authorization to issue certificates containing that FQDN to _the holder of the issuer-domain-name or a party acting under the explicit authority of the holder of the issuer-domain-name_." Who is the "holder of the issuer-domain-name" for, say, geotrust.com, rapidssl.com, or thawte.com? That's right: DigiCert. So by specifying 'geotrust.com' in your CAA record, you are implicitly also granting the various DigiCert subsidiaries authorization, which really isn't obvious at all. If we then add up the various related CA domains, our breakdown looks more like this: Or, if you prefer Pareto charts to better illustrate the cumulative concentration: Authorizing a given CA can still be too broad for your taste, which is why RFC8657 specifies the 'accounturi' and 'validationmethods' parameter extensions. There's also a draft extension for Signed HTTP Exchanges ('cansignhttpexchanges') that appears to only be supported by DigiCert and pki.goog. The usage of these parameters is quite limited: In conclusion, after analyzing around 214 million domain names for CAA records, the following are worth noting: 1) CAA records are still not widely used. Across all TLDs, only 1.4% of domains use CAA records; out of the Top 1M Domains, only 4.8%. Considering that CAA records have been around since 2010 and honoring them has been mandatory for CAs since 2017, this seems like a pretty poor adoption rate. 2) Most people don't set 'iodef'. Those domains that do use CAA records tend to use the 'issue' and 'issuewild' records, but only minuscule fraction (0.9% of all TLDs' domains; 3.2% of the Top 1M Domains) set 'iodef'. 3) Extensions are not widely used. The dominance of the 'cansignhttpexchanges' parameter here surprised me, but could be explained by being pushed without industry agreement by Google as part of their "Accelerated Mobile Pages" (AMP) framework? And finally, and most importantly: 4) A small number of CAs dominate. Only 7 Certificate Authorities account for over 99% of all CAA 'issue'/'issuewild' records (10 CAs for 99% of the Top 1M Domains). 3 alone account for over 75%: Comodo, DigiCert, and Let's Encrypt. Even though this only covers the small percentage of domains that do set CAA records, I would not be surprised if the overall use of CAs across all domains followed a similar -- and similarly centralized -- distribution. (In some markets, regional players will play a bigger role; once again the inability to get access to all ccTLD zones makes this difficult to assess.) So no, you probably could replace your giant trust bundle with fewer than... 20 or so root CA certs and not notice a difference, I'd guess. But whether that's a good thing, whether it's wise for the entire internet to place all -- well, >99% -- of its certificates/eggs into fewer than 10 CAs/baskets seems more than questionable. And that's it for today - thanks for playing "Whose Cert Is It Anyway?" โ๏ธ This thread is available as a blog post here: P.S.: This was the third blog post in a series on the centralization of the internet. Part 1, covering NS records, can be found here: Or, as a Twitter thread: Part 2, covering MX records, can be found here: Or as a Mastodon thread: |
Gregory's Server
Except, we didn't: _static_ HPKP is still very much alive, even if your company long forgot they had submitted pins several years ago:
https://source.chromium.org/chromium/chromium/src/+/main:net/http/transport_security_state_static.json