Posted by galadran 9 hours ago
Also, it's quietly, in the email space, that we're seeing real innovation while browser vendors just say "no" to everything. We should be distributing trust, not centralizing it in browser vendor security teams and Let's Encrypt.
Many web clients have chosen to default to trust stores within their own ecosystem for usability and reproducibility reasons. When I as a user run "pip install requests", I expect to be able to issue HTTPS requests. I do not expect an implicit system dependency on ca-certificates - that might not even exist on my system!
If you want all of the web clients on your system to use a centrally managed trust store, then it's your responsibility to (a) know and enforce what clients exist on your system and (b) configure them all to use that trust store.
I don't know how we fix this, but it does seem like a big problem.
The web has continued to go the wrong way in practice. (For example, browser makers rejected RFC9102 DNSSEC stapling, which could have enabled an incremental migration away from CA-centric hell.) Everything fix the existing web PKI community makes just seems to centralize trust more.
For example, Let's Encrypt has been useful for moving people off unencrypted services, but side it's now ubiquitous on the internet and had to work within the broken universal-grant CA model, it now represents a terrifying central point of failure. Had browser makers supported DANE instead, and had we embraced DNSSEC instead of casting aspersions on it, we wouldn't have needed Let's Encrypt because ownership of a domain name would have already, by that very fact, let you authenticate to anyone.
This is sort of right and sort of wrong. It's true that you could have a DNSSEC-style regime where only one entity could issue for a given domain, but as long as you're going to allow third party issuance at all, then you have to contend with the fact that most CAs want to issue in the big gTLDs (.com, .org, etc.) and so narrowing issuance doesn't help that much in many cases.
> Had browser makers supported DANE instead, and had we embraced DNSSEC instead of casting aspersions on it, we wouldn't have needed Let's Encrypt because ownership of a domain name would have already, by that very fact, let you authenticate to anyone.
This is ahistorical. By the time that DANE was designed, the WebPKI model was well entrenched and there was a huge population of browsers that couldn't really be upgraded and also only supported the WebPKI. If you wanted something that was acceptable to those browsers, it had to be WebPKI and it had to be cross-signed, hence Let's Encrypt.
I suppose you could argue that at some point after that one could have tried to deploy DANE and phase out LE and the rest of the WebPKI. I don't think that's true for the reasons that have been discussed on HN about DNSSEC, but that's really not the same as you wouldn't have needed LE in the first place.
Had we been using DANE instead of WebPKI, the response to this sort of compromise would be "aw, shucks, someone proved to be untrustworthy and they're in such a critical role in the ecosystem that there's no way to route around this DNS provider being untrustworthy."
You mean until the DNSsec key rollover completes and they're no longer in that role?
As opposed to what we have now, an indefinite period where crappy non-updated devices will still accept these certs and nothing can be done about it?
The Web PKI works great for browsers. Everything else, not so much.
(To be fair, the crappy devices¹ would probably fail to deal with the periodic DNSsec root key rollovers. But at least that's a fail-closed.)
¹ a label that includes older versions of systemd-resolved, for whatever that may mean
Basically, the design didn't have a way to distrust anything other than removal from the root store. Which may still happen, but that will take longer.
Is the update cadence of CAs that different between the sources? Is the list of CAs included so different from OS vendors and the package managers?
Can you elaborate on this innovation in the email space around PKI?
Is it a out MTA-STS or something else?
In general, email has used DNS to a greater extent than the web has to build trust mechanisms that don't depend on giant lists managed by a tiny number of browser vendors.
Well you might think, oh I can monitor the certificate transparency logs.
I would say well, good luck downloading and parsing terabytes of certificates as they are logged. Then there are CAs whose logs will rate limit you in a way such that you can't catch up to the certs being logged with one server and IP. The system might "work" but not for domain owners. Good luck.
(from this author)
Browsers might've gotten their magic revocation updates, but a lot of other things haven't… (and yeah this is "security by hoping hard enough", but still better than nothing.)
https://emudhra.we-have-a-problem.com/ tests all certs. If you don't trust that for whatever reason, https://bgp.tools/ also shows a banner at the top if you're vulnerable.
is this related to Government of India related websites and their services/websites like tax filing etc? is the impact expected to be concentrated around indian citizens availing these services?
This means that the people with these keys could MITM almost any https connection people make, not only the ones that this CA issued.
(Of course, the former isn't really intended to constrain trusted Root CAs, moreso internal PKIs. But it is an option people should know about!)
From my limited experience (using them at home) they seem to be fairly well supported in client libraries, actually!
- OpenSSL has full support, https://docs.openssl.org/master/man5/x509v3_config/
- GnuTLS has full support, https://www.gnutls.org/manual/html_node/X509-certificate-API...
- go (crypto/x509) supports everything except DirectoryName constraints, https://pkg.go.dev/crypto/x509#Certificate.Verify
- Python (pyca/cryptography) has full support, https://cryptography.io/en/stable/x509/reference/#cryptograp...
- Windows/Schannel has full support, https://learn.microsoft.com/en-us/windows/win32/seccertenrol...
- Java has full support, https://docs.oracle.com/en/java/javase/21/docs/api/java.base...
- I know that NSS also supports them from experience but (sorry!) couldn't find the docs in a few seconds of searching
- I know that Strongswan supports them well because I actually opened an issue about it a few years back and got it fixed :-)
(Just a few off the top of my head)
…but, yeah, the issue is on layer 9. Even just nailing sub-CAs to ccTLDs breaks the moment a marketing person registers a .lol domain.
Then again, the CA/B is essentially a layer 9 entity. I just refuse to believe this is an unsolvable problem (though it might need NCv2 with a whole bunch more shit to cover more human creativity in policymaking.)
SO, not all CA's are signed by root certificates already on your machine
This has always been incredibly stupid.
Those who manage the root domains should have been able to pin who they trust, and then if you WANTED to you could add someone beyond what .com or .egg or .muffin lists.
To be fair, unless I'm misunderstanding, wouldn't this be a good move?
LE has a good security record and takes itself seriously, versus these smaller CAs that seem to mess up regularly.
All things turn and curve and degrade; Google used to be the "it's perfect" darling.
> And what happens when you want to switch?
You have to update your pins and then wait long enough that you don't mind losing users who never update their software. When it's just in software you distribute, you can change hostnames in new versions and use the new CA for new versions and the old CA for old versions...
For web browsers, there's not a reasonable way to make a nicer transition. You have to serve old certs for old pins, and TLS handshakes from browsers don't include enough information to know if the client has an old pin or a new pin; or at least, mostly they don't --- if you get your pins changed and the browser TLS stack changes so the handshake changes after that, maybe you can use that... when sha1 certs were phased out, it was somewhat popular on high volume sites to look at the TLS Client Hello to decide to serve a sha256 cert or a sha1 cert.
DNS CAA only pins issuance, not acceptance; clients can not check if the CA that issued a cert was listed in DNS CAA at the time of issuance, and they do not check if it's listed at time of presentation. I'm pretty sure issuing a cert contrary to a CAA record is a mississuance and would result in sanctions from the CA/Browser forum, but clients would still accept the cert until it's revoked.
There was briefly browser support for site initiated pin on first user (HTTP Public Key Pinning), but it got dropped as mostly no one was using it and it was easy to get wrong and break your site.
There is reason why company shouldn't cheap out and use foreign vendors like this....
> An attacker with the private key of any of the compromised intermediate CAs could impersonate any website or service.
And how many more times do we need to read this before we replace Web PKI with a system that isn't as completely insane?
We already have a functioning system for delegating domain ownership in a hierarchical fashion where compromises are limited to only the subtree under the compromised entity. Let's start using it for domain validation sooner rather than later.
You say this like it's easy and simple and we are simply not choosing to do so.
Building a web-of-trust scheme that works might not be easy, but also it's not like we've been trying exceptionally hard lately either.
The broader issue is that users don't want to (and probably don't have the ability to) actually make any trust decisions; they much prefer to delegate all of the decisions on trustworthiness to somebody else. The PKI root CA system does have its flaws, but on the whole, I suspect that people like Mozilla are better stewards as to whether or not the person vouching for somebody else is trustworthy than the average or even the above-average user.
I'm not sure I'm familiar with what moment this is referring to; can you elaborate?
To your second point, that might be true in a world where the consequences of making a bad trust decision was some kind of hassle related to changing passwords or reporting your cards stolen. But we seem to be moving towards a world where it lands you in a detention facility or some other dire consequence. I think that sooner or later, users are going to realize that they want that control and will be willing to do the corresponding trust hygiene work. Besides, isn't making that kind of work easy the point of technology? We just need to do better re: making it usable rather than investing in systems we know to be unsafe.
I'm not sure that's really true. Human social organization has, until around 10,000 years ago, been centered on small groups of people where everyone literally knew each other. The ethnographic studies on non-state complex societies generally tends to show a lot of kinship-based networks that developed, and even in state societies that are facilitating long-distance trade, trade patterns and introduction into new areas is heavily reliant on membership of these kinship groups. State societies generally deemphasize these kinship groups, eventually doing away with them like in modern society, but the mechanisms for developing social trust are based on a very centralized development of the legal system--the government essentially enforces that people have to be trustworthy, or they face the wrath of government otherwise.
Essentially, in short, the idea that humans have regularly been trusting people based on asking their close compatriots who they can vouch for doesn't seem to accurately model how trust develops in societies for most of human history--you either have vouching based on direct observation (in small societies), vouching based on identity (larger non-state societies), or centralized authority vouching for people (state societies, including today).
That's not to say that we can dispense with these institutions, but they are not whence the trust comes, rather they're a sort of nucleation site around which the peer to peer trust we've been relying on for hundreds of thousands of years can coalesce. The institutional structures are an index of things that we may or may not trust, their utility is that the index lowers the information processing burden of doing so in either case.
The friend-or-foe decision started to become computationally burdensome as populations increased, and it has indeed failed to scale, but it's still in there doing its best, making it look like the centralized attempts are working because often they're aligned.
But when the people in charge decide that they no longer care to protect the people who they're in charge of, that alignment slips, and suddenly the most powerful organization on the planet can't win a war against pond scum.
The trust has always been peer to peer. We can find ways to improve it, or we can continue the charade that it's replaceable.
Also, the interpersonal web of trust is IMHO quite clearly failing in the age of mass media, and not just recently.
Well, yeah. DANE should have won. NameConstraints would be nice tooo, but who's going to make CAs use it?
And FFS, clients could at least check CRLs once in a while.
Visibility through Certificate Transparency logs would at least make it a matter of record that it occurred, though.
I agree, you can't kill a TLD operator. But WebPKI relies on TLD operators to establish identity, so I don't see what we gain from WebPKI, other than mandatory CT logs, and not having to faff about with DNSSEC :P ... both of those are pretty valuable, of course.
I'll put it another way: why do we want a CA to tell us that someone controls a domain, when the TLD could tell us? The TLD is authoritative with regard to who controls a domain; CAs can only report on what they have observed.
In the main, attacks on the DV process aren't protocol attacks; they're simple ATO attacks on registrars. The DV part of the WebPKI is certainly gross and could be improved, but evidence from the last 20 years says pretty clearly that the DV process itself is not the most urgent risk in the system.
My first hope is that we continue to ratchet security requirements for CAs upwards, and in doing so wash more and more incompetent operators out.
I don't care if you write 100,000 or 1,000,000 words: there's nothing wrong with DNSSEC or security that rides on it in principle except that it distributes trust decisions that have been centralized in those objecting to DNSSEC.
It is very bad for the internet to depend for its security on a tiny number of individuals to make global judgements about who's a bad actor.
In a DANE world, I need only trust the DNS authorities, and there are ways to boost trust in, e.g. the dot-com key management. (Could even go full ring signatures if we wanted.)
Someone over on foo.wtf.lol can't hurt me.
Meanwhile: this CA is likely to be killed outright for this fuckup.
This way, fuckups like this CA can't hurt me because they couldn't break DANE and IC couldn't hurt me (more than they can already) because WebPKI would have to approve too.
I don't think the CA death penalty addresses the problem. Just as in the physical world, the death penalty isn't a perfect deterrent.
If you care this much about your root set, consider having Claude roll you a Chromium or Firefox with a user-controllable set of roots that you ruthlessly prune and manage. Unlike DANE, which simply isn't going to happen for a whole variety of reasons, your personal root program (I gift that term to you if you want the coinage) actually could help people with your preferences.
Maybe if people implemented name constraints and the CA/B forced CAs to use them. But not as it is; unconstrained sub-CAs are a scourge on the Web PKI.
eMudhra is not such a case. They are a root CA that issues certificates to the general public all over the world. In fact, they are now the preferred vendor for numerous US universities via InCommon[1]. There is no way to meaningfully name constrain them.
Interestingly, InCommon used Sectigo prior to this year. I'm guessing eMudhra costs less.
You've been vocal for a long time against DNSSEC deployment too for no discernable reason.
Why are you against every single thing that tries to make DNS useful for securing anything?
It can also be disabled at the whim of anyone operating a resolver, as was seen with Cloudflare during the .de TLD DNSSEC snafu back in May.
This particular issue has nothing to do with "aligning authentication with the name hierarchy". The exact same thing that happened to EMudhra could happen to any TLD operator. The difference is that we have essentially no recourse when that happens, and far less ability to detect malfeasance.
What is a difference, versus DANE, is that TLS uses CT. Compromised TLDs happened recently but was found out through CT. A compromised TLD still kills the whole system for a time regardless.
I think DNSSEC still has some use in enforcing email TLS and for CAs.