I hate the concept of certificate authorities in general. I wish we had a way to do robust security without them. The idea that you need the approval of one of these companies to publish to the web without a wall of alerts is just absurd.
IMO the correct solution would be one based on DNS. (E.g. DNSSEC+DANE or something similar.) Right now (unless we bring back extended validation) the entire purpose of certs on the web is to tell browsers what private key is associated with a domain. It's silly to involve completely unrelated third parties in that process when you could just get the information from the authoritative source (DNS) directly.
> So yes shipping a CA known to have intentionally issued false certificates is very on-brand for them. Did TrustCor turn out to have done that? The last time I checked in on that, the distrust was mainly founded on some not-very-trustworthy behavior involving spyware in a related company within the same corporate umbrella. EDIT: Link to the rationale for distrust from Mozilla ... https://groups.google.com/a/mozilla.…
To be removed, a CA just needs to show it is not worthy of trust. TrustCor met this requirement and got removed. Other CAs removed in the past also showed they are unworthy of trust, but in even more blatant ways.
Yes - I know - I'm responding to the accusation in the quote, which is not at all substantiated.
I hate the concept of certificate authorities in general. I wish we had a way to do robust security without them. The idea that you need the approval of one of these companies to publish to the web without a wall of alerts is just absurd.
IMO the correct solution would be one based on DNS. (E.g. DNSSEC+DANE or something similar.) Right now (unless we bring back extended validation) the entire purpose of certs on the web is to tell browsers what private key is associated with a domain. It's silly to involve completely unrelated third parties in that process when you could just get the information from the authoritative source (DNS) directly.
No, it's not. One of the important benefits you get from this layer of indirection is revocability of trust. CAs can be removed from browsers (Google and Mozilla have both removed some of the largest CAs), and DNS roots cannot. Browsers and root store operators can pressure CAs to adopt safeguards like Certificate Transparency --- they simply won't trust CAs that don't. There is no DANE Transparency in part because nobody can pressure TLD operators to adopt it.
There are a whole variety of other problems with a DNS PKI, and with DNSSEC in particular, but when we're talking about issues like this thread, revocability is the the big thing.
Even when Mozilla does fully remove stuff from their root store, in some cases it has taken distros a year+ to ship the updated version Not to mention stuff like this: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+b... , where Ubuntu just unilaterally reverted Mozilla’s removal of a cert in their package, because it was breaking nuget… Note that this was early 2021 — Mozilla removed Symantec from their t…
For those who are interested in more details about this, I wrote a paper that examines the delay and trust discrepancies between Mozilla and its derivative root stores (e.g., Linux, NodeJS, etc.): https://zanema.com/papers/imc21_roots.pdf
Ubuntu has never seemed to take security particularly seriously. So yes shipping a CA known to have intentionally issued false certificates is very on-brand for them.
> So yes shipping a CA known to have intentionally issued false certificates is very on-brand for them. Did TrustCor turn out to have done that? The last time I checked in on that, the distrust was mainly founded on some not-very-trustworthy behavior involving spyware in a related company within the same corporate umbrella. EDIT: Link to the rationale for distrust from Mozilla ... https://groups.google.com/a/mozilla.…
You’re 100% right. They were unable to convince the right folks that they were trustworthy, and they appear to be in a prime position to abuse misplaced trust due to some fundamental conflicts of interest, but “known to have intentionally issued false certificates” is a false accusation.
There is no API to actually handle trust. If you are asking `curl` or `openssl` to verify the chain, it needs to read it from somewhere. By convention, there is `OPENSSLDIR`, for example. But that just tells us where the root certs are, not much more. In the API, I load the root CAs and check validity of the cert, nothing beyond that. And I can do that in multiple different TLS engines. Given that there is no API for…
If you can name a set of trust anchors (e.g., with an environment variable, in a configuration parameter, in a command-line argument, as a function/method parameter), then you've got the power to specify what to trust contextually. The problem is that a) apps usually don't give you such a control, and b) the names of these sets of trust anchors have to be meaningful to users.
The whole CA model is broken by the OS and browser model of "Every CA is trusted for every use case across any TLD or IP range" without any sort of context of scope except dates. Do you REALLY trust that some of these CAs aren't issuing sketchy certificates to their local intelligence agencies, as one of the Middle Eastern CAs was caught doing? Why is it every single one of the 30+ CAs that Mozilla or Google trusts can issue .com domain certs, not just ones for their local TLDs or local which would dramatically limit the blast radius for a breach? To pick on Chrome since they're the biggest, they've got Turkish and Greek, Chinese and Hong Kong and Taiwanese CAs in there, how do you think people in those countries feel about trusting TLS certs from the other?
The high bar to establish a trusted CA in terms of cybersecurity capital investments and audit requirements means there's very few developing country CAs. What if LacNIC or AfriNIC could run their own CAs, but they were scoped only to work on IPv4 or IPv6 blocks they managed?
Meanwhile, in a corporate enterprise use case, how about being able to trust a CA only to issue certs for my dev and test .local domain, possibly with a scoped range of IPs? At that point, I don't care if that internal CA gets breached and an attacker issues fake .com certs, my OSes and browsers I installed the CA on would know they're only valid for foobarlab.local on 10.10.x.x - 10.100.x.x or some IPv6 equivalent.
The whole CA model is broken by the OS and browser model of "Every CA is trusted for every use case across any TLD or IP range" without any sort of context of scope except dates. Do you REALLY trust that some of these CAs aren't issuing sketchy certificates to their local intelligence agencies, as one of the Middle Eastern CAs was caught doing? Why is it every single one of the 30+ CAs that Mozilla or Google trusts c…
> Do you REALLY trust that some of these CAs aren't issuing sketchy certificates to their local intelligence agencies, as one of the Middle Eastern CAs was caught doing?
A decade ago, probably. Today, with CT logging being mandatory in most browsers? Much less likely.
The whole CA model is broken by the OS and browser "every CA is trusted for every use case across any TLD or IP range" without any sort of context of scope except dates. Why is it every single one of the 30+ CA roots that Mozilla or Google trusts can issue .com domain certs, not just ones for their local TLDs or local IP ranges which would dramatically limit the blast radius for a breach? Do you really trust that some of these CAs aren't issuing sketchy certificates to their local intelligence agencies, as one of the Middle Eastern CAs was caught doing? To pick on Chrome since they're the biggest, they've got Turkish and Greek, Chinese and Hong Kong and Taiwanese CAs in there, how do you think people in those countries feel about trusting TLS certs from the other sides of disputes?
The high bar to establish a trusted CA root in terms of cybersecurity capital investments and audit requirements means there's very few developing country root CAs. What if LacNIC or AfriNIC could run their own CA roots, but they were scoped only to work on IPv4 or IPv6 blocks they managed?
Meanwhile, in a corporate enterprise use case, how about being able to trust a CA only to issue certs for my dev and test .local domain, possibly with a scoped range of IPs? At that point, I don't care if that internal CA gets compromised and an attacker issues fake .com certs, my OSes and browsers I installed the CA on would know they're only valid for foobarlab.local on 10.10.x.x - 10.100.x.x or some IPv6 equivalent.
If you don't then the certificates usually aren't usable at all. All modern browsers should reject certs from any root CA if the cert isn't correctly included in a CT log.
Do modern browsers check this though? It would introduce a large latency to each request, I bet none of the browsers do that. Moreover, Chrome removed the browser extension API for TLS certificate details, so it is not even possible to do CT log verification via extensions. Only way to do CT log verification would be by customising an existing TLS MITM software. As far as I’m aware no such solution exists at the mome…
> Do modern browsers check this though? It would introduce a large latency to each request, I bet none of the browsers do that.