The Chrome Root Program
groups.google.com
groups.google.com
Overall I'm in favour of this change though. Especially on Linux, distros haven't really proven to be good guardians of the root store. See the cons section in the rustls-native-certs readme: https://github.com/ctz/rustls-native-certs#should-i-use-this...
> If you’re an enterprise managing trusted CAs for your organization, including locally installed enterprise CAs, the policies described in this document do not apply to your CA. No changes are currently planned for how enterprise administrators manage those CAs within Chrome. CAs that have been installed by the device owner or administrator into the operating system trust store are expected to continue to work as they do today.
Huh that's a really cool idea. I wonder how it's implemented, as it might be useful for the rustls-native-certs crate as well...
Edit: found it: Apparently there is a bool field is_issued_by_known_root that gets set by the differerent backends. https://chromium.googlesource.com/chromium/src/net/+/2f96522...
We’re taking an approach similar to Firefox’s implementation ( https://searchfox.org/mozilla-central/source/security/manage... ), which I helped advise on in the long ago days. It may end up using like that bool, but if you read through the commit history for how that code in Chrome works, you can see there are a lot of sharp edges.
It only reads in the Root CA certificates in the Machine store.
It ignores the User store entirely.
It ignores the Intermediate CA store as well.
I bet Mozilla's logic is that Intermediate CA certificates can simply be "downloaded" dynamically, but Windows Server CAs use LDAP URLs by default, which Firefox doesn't support.
It also ignores CTLs, CRLs, revoked certificates, and a bunch of other Windows PKI stores.
Chrome was pleasant to use in that "it just worked", and this was a major reason it was adopted by large organisations and Firefox wasn't.
Please don't break this.
Firefox still ignores the local Intermediate CA store, the revoked store, etc...
> because the goal is not to reimplement CAPI and it’s 200+ undocumented (except by support contract) flags and features.
The reality is that there are orgs out there with Enterprise CA Roots that have issued many intermediate CAs and tens of thousands leaf certificates.
Because of the arrogant behaviour of Mozilla and Google, it is now incredibly dangerous to run an Enterprise CA because it is no longer feasible to revoke an Intermediate CA!
Neither Firefox, nor Chrome check Intermediate CA CRLs or OCSP by default. Chrome up until recently would honour revocations via Group Policy, but Firefox would not.
Google uses CRLSets in Chrome for CA revocation, but good luck getting them to accept your Intermediate CA key that was compromised!
Now Google is going down the same selfish path: Because Google doesn't need Enteprise PKI -- because none of their products are used extensively for private networking -- they're more than happy to break hundreds of millions of deployed Windows private networks. Who cares, right? That's the competition!
"Do not be evil" was removed, remember?
There’s more that could be said, but I can see this is an emotionally loaded subject for you, so perhaps it’s best dealt with as it rolls out. Every feature has a cost: to complexity (CTLs are notoriously ‘weird’ on Windows, for example), to security (LDAP is a terrible protocol due to BER), or simply in the maintenance costs that prevent security improvements. Software engineering is about weighing those trade-offs: do you implement the feature that 10-100 users use, or do you spend time improving things for the other billion users? There are limits to what can be supported, and limits to what is even good to support in the first place, and while such pragmatism may seem like arrogance, the reality is less malicious: it just isn’t good software.
In any event, making sure usage statistics are enabled, and bugs are filed when actually, is a good way to help prioritize.
Try 10-500 million, perhaps a billion. Most medium-to-large corporations have an Enterprise PKI issuing internal-use certificates.
> do you spend time improving things for the other billion users?
Here's the thing: Google's users and Microsoft's users are much the same people, in roughly the same total numbers.
But Google would much rather have those people be only Google's users, and not Microsoft's users any longer.
Why implement a feature that helps "the competition"?
Why implement a client feature that your company's server products don't need or use?
Why bother with the private enterprise when your company only sells stuff via the public cloud?
Why bother with security at all if the attacks don't affect you directly?
These are very important question to think about, because the answers say something critical about the future of not just "The Web", but computing in general.
Google has decided they won't bother any longer. They now control a sufficient fraction of the HTML client market to force changes onto the market unilaterally, even if it that actively harms the security of their competitors.
As long as Google's needs are met, the job is done.
Microsoft customers' needs are no longer relevant...
[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1552374
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956411
EDIT: kinda like how node_module thing got started in the first place. But I can see how this can turn into another browser war with Google and Mozilla each starting to bundle their own CA bundles. God, can we just please have DHT type for Root CA already?
[1]: https://www.androidpolice.com/2020/11/07/many-websites-will-...
What's wrong with just using the OS trust store and code/logic, perhaps with a whitelist/blacklist for anything particularly problematic where the OS trust store isn't updated quick enough?
Is Chrome going to decide that NTFS file operations are too slow next and implement their own ChromeFS in a little Chrome partition? No... Use what the OS provides...
The post linked in the article, https://g.co/chrome/root-policy makes it clear: the goal is to provide a consistent, cross-platform experience to the Web.
Users, and developers, hate “it doesn’t work on my machine” bugs, which are incredibly common. Sites that work on Chrome on macOS 10, but not macOS 11, or work on Chrome on Windows 10 but not Chrome on Windows 7. Giving developers and site operators predictable guidance, so that it “works in Chrome, works in Firefox” is good, no different than what Web Platform features you can use as https://caniuse.com
Yes, Android is important, but it’s a bit like saying the forest exists because of this specific tree here, when in fact it’s made up of hundreds of trees, of all sorts of types.
> The certificates in this store are installed as a shared library (libnss) by the package chromiumos-overlay/dev-libs/nss. It is a fork of a Gentoo upstream package with the same name, with added/removed certificates based on Google's policy.
https://chromium.googlesource.com/chromiumos/docs/+/master/c...
Given that Chrome now gets its own root program, I wonder what the future of this separate root store is.
On a practical, technical level, I’ll probably just leave the overlay in place because libnss gets grumpy when there’s no ckbi shared object to load. Chrome itself won’t be consulting ckbi (i.e. it will take the same path as Linux, which will be to consult the Chrome store, even on Chromium OS builds, and only use NSS for user-added roots and client certs).
Whether we keep that overlay in sync with the Chrome store, or stop patching it and let it match upstream, it’s neither here nor there, and mostly just about what ends up being easiest and causing the least confusion. I’m lazy, but in practice the contents there won’t matter, since it’ll be baked into Chrome proper.
The etc-based store is a little more complicated, but it’s also not used by Chrome on CrOS, nor by the system apps that only talk to Google (they use the Google service set from pki.goog). Any code using that set doesn’t use the Chromium cert verifier, which as the mail and https://g.co/chrome/root-policy explain, go sort of hand in hand with the root program, so it may just continue to use upstream as it does today.
A few years ago google started to move into the "extinguish" phase, and it's only becoming more apparent every time they announce a change
The priority of constituencies for the Web is a little different than on Android. Android gives a lot of deference to app developers, even against user wishes (think things like screenshot detection or making it hard to intercept traffic without rooting). This gives it a more “secure” reputation for some purposes, but certainly isn’t always what users want. The web has a different set of priorities, as spelled out in https://www.w3.org/TR/html-design-principles/#priority-of-co...
I’m not going to argue which is better, but I will acknowledge there are tradeoffs in both. Chrome, the browser, tries to be the user’s agent to the Web.
Sometimes, however, being the users agent isn’t always cut and dry obvious. Extensions are a great way to empower users to mix the Web as they want, but they can also be a really harmful abuse vector. Finding the balance is tricky, and I know folks aren’t always happy with how that balance is struck, but a lot of thought and community engagement definitely goes in to it.
Now, how does this relate to what you were speculating about? Well, installing roots is similarly one of those things that’s dual-use. I love tools like Fiddler and CharlesProxy, and have fought hard to make sure they work well (see the token binding discussions, which would have totally broke these tools). These tools use locally installed certs to really empower developers and users, and I don’t want to break that! But there’s also stuff like https://security.googleblog.com/2019/08/protecting-chrome-us... , which can completely destroy users’ privacy and security, using locally installed roots. So, like with extensions, there’s a balance to be had, between enabling great use cases, while also protecting users from abusive things.
Obviously, as you note, problems like this could be “solved” by not allowing locally installed roots at all. When Kazakhstan required a root to be installed to compromise traffic, for example, Android and iOS users were largely protected precisely because “install this root” doesn’t really work as KZ intended. That’s great! But it’s also got downsides, like breaking Fiddler and Charles.
I can absolutely say that the reason for this new root program is exactly what is said on the policy, and similar to Mozilla’s explanation at https://blog.mozilla.org/security/2019/02/14/why-does-mozill... . This isn’t about trying to block all locally installed certs, like Android, but about providing good, safe, cross-platform and interoperable defaults.
But I also will acknowledge that there totally are concerns about abusive roots, whether from Unwanted Software, device compromise, or the like, and this will give better tools to help communicate, explain, and warn users as appropriate, so they have a chance to make an informed decision. For example, this can close off quite a few abuse vectors for malware, today, and that’s already a win. However, any big changes to how locally installed roots work are quite a while away, and, like so many of the changes that involve complex tradeoffs, will involve a lot of research to understand users’ needs and desires and use cases. So no, this isn’t some secret plot to prevent users from managing their device as they see fit, or from choosing the CAs they trust.
The idea that software should act against user wishes isn't inspiring to me if I am the user in question, not to mention the one who purchased the hardware and software.
> When Kazakhstan required a root to be installed to compromise traffic, for example, Android and iOS users were largely protected
On the other hand, this is aligned with what I want.
First Chrome started out as a technically amazing, open source, standards compliant browser. Developers everywhere adopted it and promoted it to their friends and family. Rapid adoption ensued.
Development tools became amazing, further spurring on developers to build websites for Chrome primarily. Creating a vicious cycle, now others need Chrome to enjoy these websites.
Then gradually Chrome starts stripping away user freedom in the name of security and privacy. Google added auto-update to force Chrome browser upgrades on every user. This pushes the web into a monoculture where Google can further centralize and establish control.
It all feeds into the same funnel.
They know that, and they're making the tractor beam stronger.
The quality of search results and user customization of Chrome are going down as more properties on the search results (AMP, AdSense in the top results) lead to Google monetization flows. The web doesn't even need information any more - just clicks.
The DOJ needs to pry Google apart like a clam.
For example, adspace is the biggest offender in terms of cripling browser resource overload. If they implemented, say a 500kb cap for JS in IFRAME, and disabled JS entirely for IFrames more than two layers in HTML>IFRAME>IFRAME get JS, another layer doesn't... that would be a massive boost to actual performance, especially in low-resource devices.
Unfortunately, such limitations will NEVER be implemented by Google, and Firefox getting most of their funding from Google as well won't do it. MS might, but I don't see them making those kinds of changes in their fork.
Even as a separate entity, Chrome would have to get funding from somewhere. Also, where would ChromeOS fall, or Android? What would stop Google from forking and starting all over again?