CA authorities can set the date when the certificate was issued to any date they like, bypassing the "trusted until" mechanism. Such a CA can still issue any certificate they like, pass browser checks and do MitM. In this way you still trust them to sign the correct issue date while you want to distrust them. Isn't Mozilla's mechanism kind of weird by being not "too simple"?
Linux Certificate Authority root stores have a too simple view of 'trust'
81–90 of 120 posts
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#82Earlier quoted context omitted.
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 n…
You raise some good points. There are definitely some benefits to having a diversity of different trust anchors rather than just one. The problem though is that the way things are currently set up that diversity is somewhat of an illusion; DNS is still a central point of failure for all CAs (e.g. via the ACME DNS challenge), and each individual CA is also a single point of failure unto itself (a CA can issue certs for any domain, not just those of its customers).
I also think you may be underestimating the amount of leverage browser developers have over DNS, should they choose to exercise it. If Google, Apple, Microsoft, and Mozilla all agreed tomorrow that they wanted to migrate the web to a new set of DNS root servers they could probably do it. (Though yes, it would be a huge ordeal for everyone involved.) The real reason we haven't gotten DANE transparency (or anything similar) is simply because it hasn't been a priority for browsers. (Why pressure DNS roots to improve a system that you aren't even using in the first place?)
Still, I can't deny what you're saying. The CA system is probably a lot more flexible than a naively designed DNS-based system would be. I'll have to think about that a bit more. Maybe it would make sense to have something like SCTs in the certificate transparency system, where a number of different independently operated organizations all have to sign off on the validity of each cert _in addition_ to the DNS operator that actually issued the certificate. That way you'd get the benefits of diversified trust anchors without the downside of having hundreds of distributed single points of failure.
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#83Earlier quoted context omitted.
Java uses those formats too. Java actually solves the complaint in this thread, and has done for a long time. The JDK has its own root store program run by Sun and now Oracle, TLS APIs use the bundled root store automatically, it provides tools to manage that root store, exceptions are easily rendered to users in a generic way, and it provides a mix of high and low level APIs. What you're probably thinking of is the…
Java has the exact opposite of a solution to this, though their intentions were very admirable. PKCS#12 is a terrible solution, and Java does it's best to enforce it, and it's move to adopt it further is the exact opposite direction that everyone has been moving in. What everyone's realized in recent years is that trust is context-dependent, and that you don't want to use the same roots of trust (or trust anchors, or…
Well, but the default of having a bag of certs with a trust store program does make sense - apps want to just be able to talk to random web servers in a secure manner and that's the only way to get that.
In many use cases you could use a store with only a self-signed certificate. That works, the APIs make it straightforward enough. It has many advantages when possible, e.g. you can set the expiry time to so far in the future it never expires, you don't have to muck about with LetsEncrypt and CAs. You do have to control the client and the server. If your frontend is a web app that's a problem. If it's a mobile or desktop app that's easy. Control over the client has other advantages too like not needing HTTP load balancers anymore (in many cases), reducing costs.
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#84Note that if you don't trust the CA, you shouldn't trust the issue date either. A dishonest CA would backdate any certificates signed. So having an arbitrary cutoff date in software seems unnecessary. If you still trust the CA to behave honestly for now, then you can simply instruct them not to issue any more certificates. If you don't trust the CA to act honestly for now, then you need to remove them from the trust…
Trust isn't black and white. Removing the cert entirely breaks existing applications which comes with its own risk. Using TrustCor as an example there is no hard evidence they have done anything wrong. Is that enough to justify cutting off their clients? What if one of those clients is a major antivirus vendor etc. with pinned certs in their software? Or road signs etc.?
If they pinned a cert in the application, why use the root store at all?
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#85Earlier quoted context omitted.
> There's no reason why some committee couldn't sit down and standardize a format for ancillary data such as the trust date cutoffs mentioned here They already have ( https://www.rfc-editor.org/rfc/rfc5280.html , https://www.rfc-editor.org/rfc/rfc6960.html ) but CRL/OCSP functionality not implemented in most libraries because it's hard and thankless work.
AFAIK those are standards for allowing CAs to revoke certificates. Trust conditions for root stores are a completely different thing. Or at least, I'm certainly not aware of any mechanism in the CRL standard to "partially revoke" a CA certificate based on complex conditions like "What's the notBefore date on the leaf certificate we're currently validating?".
Ah I see, you're right I guess they didn't contemplate the scenario of "we want to distrust this CA - against its wishes - but we still trust it enough to make it an orderly transition instead of an emergency". I guess it was previously assumed that CA trust would be binary and that CAs would be cooperative - seems like a pretty common evolution that internet standards go through.
The problem is, code that handles these things is safety critical and requires real and sustained investment to be reliable. Given this overhead (and the gaps in CRL/OCSP support that I mentioned), it's unclear if this use case will be common enough to commit to supporting.
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#86Earlier quoted context omitted.
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 n…
Isn't there an implicit trust on DNS already for domain validated certificates?
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#87Earlier quoted context omitted.
There’s a surprising amount of old Unix software like Postfix, that by default doesn’t actually validate certificates.
When I renewed my Let's Encrypt certifcate the last time I noticed that my postfix was still using the certificate that had expired 3 months later. I don't receive a whole lot of email on that machine, but I did not notice any delivey failures. I started to think (but not check specs): Is it even defined what domain name should be checked? MX records can be different from server names. Maybe certificate checking is j…
Considering you basically can only get a certificate for a domain name that refers to a host (and offering an IP address for an unqualified domain name is an anomaly) I’d expect the required subject to be the hostname. But the RFC does not specify it:
The decision of whether or not to believe the authenticity of the
other party in a TLS negotiation is a local matter. However, some
general rules for the decisions are:
- A SMTP client would probably only want to authenticate an SMTP
server whose server certificate has a domain name that is the
domain name that the client thought it was connecting to.
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#88Note that if you don't trust the CA, you shouldn't trust the issue date either. A dishonest CA would backdate any certificates signed. So having an arbitrary cutoff date in software seems unnecessary. If you still trust the CA to behave honestly for now, then you can simply instruct them not to issue any more certificates. If you don't trust the CA to act honestly for now, then you need to remove them from the trust…
It was not said at all why that CA lost Mozilla's trust. If their key were leaked of course backdated certificates could be produced at any time.
See https://www.theregister.com/2022/12/02/mozilla_microsoft_tru... for information about the revocation. It's not about a leak, it's about allegations of malfeasance.
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#89Earlier quoted context omitted.
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…
Chrome and Safari require that TLS certificates include cryptographic promises of future log inclusion ('SCTs') from N trusted CT logs. As far as I know, neither of them actually contact the log's API endpoints to make sure that this has gone through, but in practice IMHO it's not much of a security gap for various reasons.
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#90I'm surprised systemd hasn't solved this problem already.