> I've flagged this as a SECURITY matter for CAs to
carefully review, because in the cases where a third-party, other than the
Issuing CA, operates such a certificate, the Issuing CA has delegated the
ability to mint arbitrary OCSP responses to this third-party!
> For example,
consider this certificate https://crt.sh/?id=21606064 . It was issued by
DigiCert to Microsoft, granting Microsoft the ability to provide OCSP
responses for any certificate issued by Digicert's Baltimore CyberTrust
Root. We know from DigiCert's disclosures that this is independently
operated by Microsoft.
If certificates are BS, give me hosts.txt entry I can point INSTAGRAM.COM that my browser will actually honor. It should be easy.
Certificates are problematic. But that's because the world is problematic. They were much more problematic 10-15 years ago. Google and Mozilla drastically mitigated their problems. They're still imperfect, but anything that expresses web trust across the entire world is always goign to be imperfect, and the webPKI at least has some stakeholders that are both empowered and deeply give a shit about security.
Yep. Revocation was broken by design so hardly anything supported it, and now the implementation is broken so revocation is getting revoked. The whole thing is ridiculous.
Indeed. I am still in awe people supportive of PKI are referred to as "security experts". PKI is literally where we decided that a bunch of companies nobody's heard of should all be the Most Trusted for the entire Internet, and be able to tell us if everyone else is trustworthy. And then our web browsers, one of which is run by an adtech company, should decide whether or not to trust those entities, and whether or not to let the user override that decision about trustworthiness, to show us the website we wanted to get to.
The PKI, like democracy, is the worst system except for all the others.
I think the main alternatives people suggest are
- something involving a distributed ledger, where revocation isn't even an option, so that clearly doesn't make it better than the current system if we're talking about revocation being a mess (we could just amend the current system to get rid of revocation and throw out a whole bunch of technical complexity if we wanted)
- something involving DNS, which also involves trusting a bunch of companies nobody's heard of (sometimes the same companies, in fact?) who are hardly obviously better at operating cryptographic infrastructure than the existing CAs
- a TOFU approach like SSH, which hasn't been demonstrated to scale well beyond the dozen or so machines in your known_hosts file (most large companies are using something other than TOFU even for internal SSH)
I don't think PKI is an objectively good system, it's just difficult to picture a better one. The main flaws with PKI in practice aren't really about the companies nobody's heard of or a web browser being run by an adtech company - the main flaws are that people want a lot of things out of the system, some of which are contradictory, and running cryptography at this level of scale is genuinely hard. The alternatives don't really address those problems.
A DNS-based system reduces the attack surface for any given domain massively: The gTLD registrar and your domain registrar become the sole entities that can create trusted certificates involving your site.
Right now, how many different companies could issue a microsoft.com cert if compromised or sketchy? Hundreds?
Right now CAs delegate trust to bunches of questionable sites as seen here with poor oversight or security based on business interest. On a DNS-based system, the entities involved are limited to those who actually manage your DNS.
It also removes the agency of browsers to decide who does and doesn't get to play, which is the current system.
The attacks are different, though. Under Certificate Transparency, approximately no one can issue a microsoft.com certificate and get away with it. Under a DNS-based system, the domain registry can do whatever, and there's no effective way to distrust them - if Verisign (who still manages .com, but who was too incompetent to run a CA and sold it to people who have been hard at work trying to clean up the mess) does something unreasonable with .com, the only option is for Microsoft to find a different TLD.
Given that most of the problems with the CA system historically have not been active attacks but incompetence, I don't think we win much from moving to a system where we can, in fact, kick TURKTRUST out of the pool to one where the question is whether .tr remains part of the internet or not. If Verisign screws up with .com in any way short of revealing a letter from the FBI saying "Please help us MITM Windows Update," there will be immense pressure to allow Verisign to continue being the .com registry and continue holding the .com signing keys.
For similar reasons, I'm not convinced that moving from "Hundreds of unqualified companies could issue a bad cert, but hopefully they won't" to "One unqualified company could issue a bad cert, but hopefully it won't" is a meaningful benefit. It doesn't reduce the theoretical bounds on the attacks, and again in practice, these hundreds of companies haven't been misissuing. (The present story is about mis-delegating the power to issue revocation/non-revocation responses, which is certainly a problem, but only relevant in practice if there are actual end-entity certs that are misissued in the first place.) So while it certainly feels better to have fewer entities that can sign - and to be clear, I am all for distrusting many if not most of them - I don't think it addresses either the fundamental theoretical problems nor the actual real-world attacks.
> Verisign (who still manages .com, but who was too incompetent to run a CA and sold it to people who have been hard at work trying to clean up the mess)
The Verisign CA function was sold to Symantec. That name might ring a bell too, because with these CAs set to be distrusted as a result of Symantec's mismanagement the whole business was again sold to DigiCert in 2017.
I think the perverse part of your reasoning is that you think .com is trustworthy now. It's one of the worst run registries. Its popularity with businesses probably tells you more about how scammy most businesses are than whether .com is trustworthy, and not very much about either.
Not sure if you're directing that at me or the parent comment - my position is definitely that Verisign should not be trusted with certificate signing authority over .com. The comment I'm replying to seems to advocate Verisign (and nobody else) being able to issue microsoft.com certs, which I think is a bad idea.
It was supposed to be a "proof of stake" originally I suppose, if a company was caught doing shady thing it would lose its CA status so they're incentivized not to do so. Sort of like internet notaries.
That might have worked decently in the early internet but it does seem seriously flawed with the current stakes.
That being said, what's the alternative? TOFU? Web of Trust? Those have massive security implications as well. They have the advantage of putting the user back in control but given that the vast majority of the people using the web today doesn't have a deep understanding of the underlying technology and security model I don't see how this wouldn't end up in a massive catastrophe.
The problem is a lot of companies have done shady things and they are still participating in PKI. And a huge issue is that I can't pick my trustworthy parties: For instance, I do not trust Google. But a huge portion of the web won't work unless my browser assumes Google can issue certs for any domain in the world. I also don't trust a half a dozen CAs in countries I don't deal with and would rather prefer not have access to at all. When a Chinese PKI provider fails, I first wonder why I'm even trusting these CAs to begin with.
I'd prefer a system backed by DNS, and based on verifying the ownership of domains and the authorized DNS provider for that domain. Presumably, in my example, the only domains Google would be authorized to secure would be domains provided via Google's DNS and domain products.
> For instance, I do not trust Google. But a huge portion of the web won't work unless my browser assumes Google can issue certs for any domain in the world.
Um no. Google's four production roots (GTS Root R1 through R4) are essentially dormant. You could (but probably shouldn't) manually distrust these roots with no impact.
The interesting thing is that web browsers can make people "get on board" with anything. Most of the PKI and TLS changes in the last couple years have happened because Chrome/Firefox/Safari have decided to say "this or your page won't work".
Understanding where web security is right now is about understanding who is making the decisions (regardless of any claims about committees and processes), and what motivations they have to make the decisions they do.
More precicely, it means that compromising the public key infrastructure requires compromising one specific CA, rather than compromising any single CA out of hundreds. Ideally, we would it to instead require compromising all CAs out of hundreds, but as long as the defective-by-design X.509 PKI is used, that's not very possible, much less likely.
Pretty much. The whole business model never really made sense: the relying parties have no relationship with the certificate authorities, while the HTTPS servers are the customers of the CAs.
I think it would make a lot more sense for certificates to be issued by domain owners, esp. since the original idea of tying sites to real-world businesses (e.g. with Dun & Bradstreet numbers) has been reduced to just verifying domain-name ownership.
Edit: I think people misunderstand what I am saying here. What I mean is that I think that when one purchases a subdomain of domain, that domain should just issue a certificate — and that domain should only be allowed to issue certificates for its children. So e.g. if one purchases foo.com, then com issues a certificate for foo.com; if one purchases bar.net, then net issues a certificate for bar.net; if one purchases baz.ac.uk then ac.uk issued a certificate for baz.ac.uk. This is essentially what Let's Encrypt and ACME already do: com has the technical ability to reassign any of its subdomains at any time it wants to, and can get a certificate issued for any of them by reassigning & registering a certificate.
And while we're at it, maybe we could kill ASN.1 with fire?
Edit: if you downvoted for this, you have never tried to debug an ASN.1 BER file.
Then there's the whole issue of putting domain names/common names inside the certificates, but relying on external verification; rather than just having the DNS NICs directly sign for domains they have obvious authority over.
> I think it would make a lot more sense for certificates to be issued by domain owners, esp. since the original idea of tying sites to real-world businesses (e.g. with Dun & Bradstreet numbers) has been reduced to just verifying domain-name ownership.
The problem with that approach is that anyone can create a certificate for any domain; so if I go to "example.com" then it's kinda hard for me to detect if my connection is being MITM'd, especially if this is the first time I'm visiting example.com.
This is why ACME requires a verification that you actually control example.com (via http or dns).
I don't think the CA model is perfect by any means, but I don't think it's completely without value either.
>The problem with that approach is that anyone can create a certificate for any domain; so if I go to "example.com" then it's kinda hard for me to detect if my connection is being MITM'd, especially if this is the first time I'm visiting example.com. //
I thought they meant the .tld registry would issue the certificate, so any registrar could sell you the domain+cert but it would have to come from the registry (ICANN say, for .com).
Can't the DNS data have a hash of the cert to avoid 3rd party certs (unless the 3rd party controls the domain registry entry, but then MitM is a [ahem] dead cert).
DNS providers should be your HTTPS providers though. Presumably the certs your browser would have to "just know" would be for the root TLDs, so you could verify with them what DNS provider a given domain was entrusted to, and then query that DNS provider whether or not your domain's certificate was legitimate.
The idea that any CA can issue a valid cert for any domain is the heart of what's wrong with PKI.
The name constraint extension (https://tools.ietf.org/html/rfc5280#section-4.2.1.10) can help a lot with that, we chose to trust CA for all names but we could have had CAs for a way more limited set of domains.
> The problem with that approach is that anyone can create a certificate for any domain; so if I go to "example.com" then it's kinda hard for me to detect if my connection is being MITM'd, especially if this is the first time I'm visiting example.com.
You misunderstand what I mean: I advocate that the owner of .com be permitted to mint certificates for foo.com, bar.com, since right now the owner of .com and can point those subdomains to any host he wishes, and then generate a certificate using ACME (because he actually controls every subdomain of .com).
Oops, sorry; I misunderstood your comment. I thought that with "domain owners" you meant "the person who registered the domain" (i.e. self-signed certs).
Using DNS providers for certificates is an interesting idea; one I haven't heard before. I can't really think of any downsides of that at the moment.
> original idea of tying sites to real-world businesses
Ironically, the only system PKI had to attempt this, Extended Validation, is opposed by the loudest voices in PKI today. Despite arguably being the only real benefit PKI potentially offered: Notarizing that a domain really belonged to a given real-world entity.
EV had flaws, but it should've been improved, not axed. Security detached from people-understandable real-world entities will never provide real security, because at the end of the day people still need to interact with the system.
> For example, consider this certificate https://crt.sh/?id=21606064 . It was issued by DigiCert to Microsoft, granting Microsoft the ability to provide OCSP responses for any certificate issued by Digicert's Baltimore CyberTrust Root. We know from DigiCert's disclosures that this is independently operated by Microsoft.