The issue here seems to be that Mozilla/Google/Microsoft are the ultimate trust authorities for TLS but that is not reflected in how things are structured. If Mozilla/Google/Microsoft certified the current root trust authorities then an OS could just download the whole mess from Mozilla/Google/Microsoft and could check the validity of them on their own taking into account any revocations.
Linux Certificate Authority root stores have a too simple view of 'trust'
101–110 of 120 posts
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#102Earlier quoted context omitted.
That was just a hypothetical example to illustrate how much power browser vendors have over the web; they wouldn't need to literally migrate to a different DNS root in order to effect change in this space, but I maintain they absolutely could go that far (again, hypothetically) if they all agreed and there were a sufficiently compelling reason. Browsers always had full control over CA root programs, it's just a quest…
I don't think this is really true at all, and I think it underestimates (significantly) the amount of behind-the-scenes work that went into the current WebPKI situation with activist root programs. I don't think there's any reason at all to believe that browsers would have similar success governing a DNS PKI, and there are specific reasons --- evidence, even --- to believe they wouldn't. We can go round and round on…
Like I said, I agree with you that a naive, purely DNS-based PKI would be less flexible in that regard. That was a good point, and well noted.
However, the current status quo is sort of ignoring the big DNS-shaped elephant in the room. You can build all the validation and transparency solutions you want on top of the CA system, but it's still fundamentally dependent on the security of a DNS system that currently requires no cryptographic assurances that the records the CAs are validating against are actually correct.
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#103Earlier quoted context omitted.
Their strong point has always been design and branding. I love their fonts and a few years ago they were the only ones with a patched libfreetype that didn't make your eyes bleed. As for engineering decisions, let's just say better stick with debian on anything non-desktop.
The only issue with Debian is if you want the latest version of some application, e.g. Firefox then installing it is far from a nice experience. And Debian testing is quite unstable (I run it on my laptop so I know). Love it for my servers but it is not very convenient for the desktop.
Flatpak exists; Nix exists; Guix exists. All of them make it easy to have newer software without caring about your Debian package versions.
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#104I also have a problem with Debian method of compiling a list of CAs.
ca-certificates package rolls in Java and Mongo CAs as well as Mozilla.
Their tools to do that is also not very clear on how they are put together the ca-certs either from 32 different subdirectories.
A (ahem) short write up that also includes suggestion of improvements. Debian bug has been filed but the Debian maintainer does not seem to be interested in moving this along.
https://egbert.net/blog/articles/ca-certificates-rebuild-on-...
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#105The choice of what CA certificates to "trust" should, optionally, in some circumstances, be the computer owner's decision. For example, when the issue with TrustCor was made public, Android users could disable the TrustCor certificates. Whether that actually works, I cannot say. The certificates are probably still there, not removed, not deleted. Same goes for disabling certificates within the browser. This is likely an illusion of owner control. That a system of "trust" is provided by a company that many do not trust is comical by any objective measure.
Personally I rely on a TLS forward proxy that uses the certificates in /etc/ssl/certs, as represented by ca-certificates.srt. Thus, I can remove certificates, regenerate ca-certificates.crt and effectively deny certificates that the advertising-supported browser company chooses to accept.
Web browsers from advertising companies, or organisations that subsist from advertising company profits, like Mozilla, ignore /etc/ssl/certs. They do not allow computer owners to remove and delete CA certificates. They refuse to allow the computer owner to add their own choices for CA certficates, e.g., certificates generated by the owners themselves, without forcing annoyances on the owner to try to discourage such owner control.
The "CA system" should be accountable to computer users, not advertising companies, or organisations that depend on advertising company profits, not "tech" companies. As it stands, computer users are locked out of the decision-making process with respect to CA certificates. The CA system has become a tool of "tech" companies that seek to commercialise every aspect of the internet. The fact is, much of the data "protected" by TLS is data belonging to or about computer users that is being sent to "tech" companies without the user's informed consent. In effect, TLS is used to stop the computer owner from seeing what data is leaving their computers and networks.
We need a CA system that is governed by computer users, not "tech" companies. All computer owners should not be discouraged from trusting themselves. The CA certificates computer owners generate should not be discriminated against in favour of ones approved by "tech" companies. Someone is no doubt going to reply to this with something about LetsEncrypt. But that is not letting users trust themselves. It requires users to rent domain names and ask to be trusted by LE. It is part of the existing CA system where users must (cf. may) let third parties decide who is trustworthy.
curl -4o 1.csv https://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat
grep TrustCor 1.csvRe: Linux Certificate Authority root stores have a too simple view of 'trust'
#106I wonder if it would be possible to configure a browser (or an entire OS) to use TOFU on the CA level. "Hey, this page uses a cert signed by $THIS_CA, would you like to trust it?" Then instead of shipping whitelists, you could ship blacklists, which is presumably simpler and more future proof.
How would I know if I should trust $THIS_CA? That's why it's good that the browser vendors do this, they know better than me which ones are trustworthy.
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#107Correct, it is too simple.
The problem is very broad though. CA/B forum is very effective for what it does, but equivalents for other uses are less so.
Most places crib and slightly rework the Mozilla CA pack with highly variable levels of maintenance and accuracy.
macOS and windows have richer models, but integrations are often poor. For many years homebrew had code that seeded an OpenSSL compatible pem with explicitly untrusted certs on macOS.
We could do with something as effective as CA/B that covers more use cases. Along with it should come some amount of reference implementation material and regularly updated test vectors.
Essentially we need the client side of let’s encrypt, and it can’t be let’s encrypt that does it.
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#108I wonder if it would be possible to configure a browser (or an entire OS) to use TOFU on the CA level. "Hey, this page uses a cert signed by $THIS_CA, would you like to trust it?" Then instead of shipping whitelists, you could ship blacklists, which is presumably simpler and more future proof.
How would I know if I should trust $THIS_CA? That's why it's good that the browser vendors do this, they know better than me which ones are trustworthy.
This whole story seems to prove that that isn't true.
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#109Earlier quoted context omitted.
Their strong point has always been design and branding. I love their fonts and a few years ago they were the only ones with a patched libfreetype that didn't make your eyes bleed. As for engineering decisions, let's just say better stick with debian on anything non-desktop.
The only issue with Debian is if you want the latest version of some application, e.g. Firefox then installing it is far from a nice experience. And Debian testing is quite unstable (I run it on my laptop so I know). Love it for my servers but it is not very convenient for the desktop.
There are other issues with Debian. They will radically rearrange upstream software to follow their own standards (e.g. try using Tomcat on Debian sometime). This is bad enough when they apply it to regular software, and downright insane when they do the same thing for security-critical software. It predictably caused quite possibly the worst general-purpose OS bug in history (their SSL key generation one). They did not change their policy in response to that incident and see nothing wrong.
Re: Linux Certificate Authority root stores have a too simple view of 'trust'
#110Earlier quoted context omitted.
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 fo…
> 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.
They're already pushing DNS over HTTP.