Many of the root certificates on Windows are not needed

https://hexatomium.github.io/2020/10/17/001.html

by svenfaw • 6 years ago

255 113 6 years ago

hexatomium.github.io

billpg2• 6 years ago

The rot started when browsers started including root certs as trusted by default.

gruez5• 6 years ago

As opposed to what? Using the OS's trust store? Getting the user to manually trust CAs?

billpg2• 6 years ago

When browsers default-trusted one CA, others companies, quite reasonably, wanted a piece of the action and asked to be included too. Time passed and we, the general public, are no longer part of the conversation about who should be default-trusted.

What if the browsers (and OS) didn't default-trust anyone? The various CA companies would have to include the general public in their public relations. We'd see CAs advertising for users to trust their roots. If a CA ever screwed up, they would feel it.

Another part of the rot is that TLS certs can only have one root CA. If I decided I don't trust DigiCert, I would effectively cut myself off from Hacker News, because a site can only have one root CA. If a site could have multiple CAs, I would still be able to connect so long as I trusted one.

chrismeller• 6 years ago

For reference. I can’t actually find a list of Google’s right now.

Mozilla: https://wiki.mozilla.org/CA/Included_Certificates

EDIT: and yes, it would have been nice for the author to link directly to these... Google clearly has their own, but obviously there’s some debate about what that means.

gruez5• 6 years ago

google's list seems to be here: https://android.googlesource.com/platform/system/ca-certific...

saagarjha• 6 years ago

Is that not Android's list? Or does Google ship those on all platforms it runs on?

mrkstu4• 6 years ago

Chrome uses the OS level cert store, whereas Mozilla uses it's own.

ocdtrekkie• 6 years ago

This is configurable for both, I believe. It's common for enterprises to switch Firefox to use the OS store to support internal certificates.

hda111• 6 years ago

What do you mean by Google? Google Chrome uses whatever the operating system provides. Nothing specific in Chrome. Firefox uses their own store.

sleevi7• 6 years ago

Chrome on ChromeOS has had its own trust store for ages. Chrome on Android similarly uses Google’s Android store.

slezyr• 6 years ago

https://source.chromium.org/chromium/chromium/src/+/master:n...

ehsankia• 6 years ago

Great podcast episode which discusses Mozilla/Google's CA lists, as well as the story of Gervase Markham (who recently passed) working on making the first fully open and transparent root program at Mozilla.

https://darknetdiaries.com/transcript/3/

sleevi7• 6 years ago

For folks discovering this: Unfortunately, this isn’t a good idea, and can seriously harm your system.

I’ll be the first to tell you that I believe Google and Mozilla have done a lot for supervising TLS, but realize that the trust stores contain many other non-TLS purposes, and with the CAs constrained from TLS issuance (e.g. only trust for S/MIME).

CryptoAPI, for its warts, is actually beautifully engineered, in that Microsoft has had the ability to add arbitrary constraints and properties to certificates from the very first release (via CERT_PROP_IDs). You don’t really see these in the UI; you only find out about them in WinCrypt.h, or via debugger stepping. However, it means that even if the UI is showing “trusted for TLS”, Microsoft may have disabled trust for TLS via the extended properties, which their APIs respect, and which are delivered through authroots.cab

You can see a little bit about this at https://github.com/crtsh/certwatch_db/issues/69 and http://unmitigatedrisk.com/?p=259

Approaches like the OP link fail to take that into consideration, and can easily break core OS services, non-TLS cases like code signing or S/MIME, or even reintroduce trust in CAs that Microsoft has programmatically disabled.

BuildTheRobots• 6 years ago

CryptoAPI, for its warts, is actually beautifully engineered, in that Microsoft has had the ability to add arbitrary constraints and properties to certificates from the very first release (via CERT_PROP_IDs). You don’t really see these in the UI; you only find out about them in WinCrypt.h, or via debugger stepping. However, it means that even if the UI is showing “trusted for TLS”, Microsoft may have disabled trust for TLS via the extended properties, which their APIs respect, and which are delivered through authroots.cab

I mean no disrespect, but if you need to look through header files or use step-through debugging to actually find out what constraints apply to a certificate, especially when the ones actually reported for the certificate don't actually apply in reality then "beautifully engineered" doesn't seem like the right adjective to use.

edit: I don't see this as a documentation issue; when the only interface you provide the user says one thing but stepping through the code reveals that that's entirely not true for certain items in certain circumstances, then having a better ReadMe is not the issue here.

sleevi7• 6 years ago

I suppose it’s a question of whether you count “documentation” as engineering.

It is elegantly complex and featureful. And (sometimes intentionally) poorly documented, as much of that implementation is seen as “an implementation detail”.

tasogare• 6 years ago

It can be beautifully engineered yet poorly documented. It happens to quite a lot of software actually.

GordonS• 6 years ago

As someone who's actually had to use the CryptoApi, I think it's unpleasant to use, and often the documentation isn't good enough. There is also usually at least 4 different ways of getting to the same result, which makes things very confusing. And some features are only supported from Windows 7/10.

"Beautifully engineered" is not the phrase that comes to mind.

CobrastanJorji• 6 years ago

It could certainly be the case that it's poorly designed, but it's not necessarily the case just because they've hidden the feature from the UX.

First, the backend constraints may be ideal despite whether they've bothered exposing any of them in the UI. Second, not exposing them in the UI may have been an explicit design decision and not just trade-offs. It's possible that a root certificate list was deemed complicated enough without adding a zillion more hard-to-debug toggles that might allow curious users to accidentally break something in a way that would be very confusing, and only allowing programmatic access was deemed to be best because likely the settings would only be used by enterprises managing their fleet or some such.

0xCMP• 6 years ago

Pretty bad that “trusted” could mean blocked and it was only possible to know this in Windows 10

tialaramex6• 6 years ago

The approach Microsoft took here encourages something we both I think agree is a bad idea, roots used for multiple potentially conflicting purposes. The owner of the multi-purpose root will either make a big fuss when policy changes down the road make that conflict painful or worse they'll persuade themselves that we can't really have meant what we just told them because it's so painful, "obviously" the policy change doesn't apply to their multi-purpose root and they'll ignore it until discovered.

If for example Microsoft had separate "Code signing" and "Web PKI" trust programmes then you get two good things for the price of one: Less incentive for CAs to do things we'll regret even if they don't; and clarity for users about the purpose of the trust relationship.

Mozilla could do better here too, it's actually not easy to discern from Firefox which built-in CA roots are actually trusted in the Web PKI, and it's outright impossible as far as I know to discover any of the special case restrictions described in https://wiki.mozilla.org/CA/Additional_Trust_Changes from the user interface of the software itself.

btown• 6 years ago

roots used for multiple potentially conflicting purposes

Wouldn't this lead to a proliferation of protocol/purpose-specific roots, to the extent that there might be so many critical roots that administrators become careless about vetting requests to add a root, or audit logs that a root is added?

It feels like the solution is a better UI to visualize the many-to-many relationship between roots and protocols/purposes, rather than requiring every root to be single-purpose.

tinus_hn• 6 years ago

So it’s hidden magic, yet the EULA states you are responsible for choosing which roots to trust.

scoot_718• 6 years ago

If you can't even remove CAs from the trust store without breaking it, then it doesn't fucking work, does it?

yonixw• 6 years ago

Distrust Amazon Root CA 1? This is the root CA for a lot of AWS API gateways. Waaaaay Overkill.

iameli• 6 years ago

Firefox doesn't trust the root CA for a lot of AWS API gateways?

0xxon• 6 years ago

The fact that some root stores/browsers don't trust some CAs is actually quite common. There will be some cross-sign from another CA that is trusted in Firefox in this case.

Stuff like this is quite common; we published a paper on this recently if you are interested in details: https://arxiv.org/abs/2009.08772

CrendKing• 6 years ago

Those selected in the screenshot are included in the Mozilla list, thus to be trusted. They instruct to distrust the inversion. Here's quote from the instruction:

    2. Right-click the selection and click Invert selection
    3. Right-click the selection and click Distrust

parliament32• 6 years ago

Interestingly, Debian (in the ca-certificates package) only has 122. These are from Mozilla AFAIK.

tialaramex6• 6 years ago

All of the Free Unixes ship roughly the Mozilla trusted CA list yes. Historically lots of them notionally had independent programmes, but they didn't actually do the maintenance/ oversight work necessary, so it's like if they'd just shipped Linux 1.3.48 forever. 1.3.48 was a pretty good release at the time, but er, not five years later. Just auto-applying Mozilla's changes is better.

However this isn't entirely an apples-to-apple comparison. That package in Debian is for the Web PKI, CAs trusted to issue specifically for DNS names (and rarely IP addresses) for services on TLS, thus mostly the web but also IMAP, HTTP and other protocols that can use TLS. That's it, no other purposes are warranted.

Whereas Microsoft ships roots trusted for several other purposes their users care about, including code signing for both application software and drivers, and document signing (used in some jurisdictions to give legal effect to a digital signature on a document, not to be confused with electronic signatures which are just an image of a written signature) and so on.

morpheuskafka• 6 years ago

How does Apple's iOS/macOS trust store look, by comparison?

willstrafach• 6 years ago

The list can be found here: https://support.apple.com/en-us/HT210770

xyst• 6 years ago

I don't know how to check for iOS, but macOS is showing 164 trusted certificates for 10.15.7. Via the "Keychain Access.app", select the "System Roots" item, then select all of the items in the right panel, then open the context menu using the two-finger tap method (or control + mouse click)

If there's a better way to check this, feel free to post

FreshFries• 6 years ago

file:///System/Library/Security/Certificates.bundle/Contents/Resources/TrustStore.html

Your method (164 like you) and this one (213), yield different results on my system (10.15.7).

EDIT: my bad

TrustStore.html also contains Untrusted & Blocked Certificates.

dolmen• 6 years ago

Use this command to extract the list of root certificates:

    security find-certificate -a -p > all-certs.pem

You can then dump each certificate:

    split -p "-----BEGIN CERTIFICATE-----" all-certs.pem cert-
    openssl x509 -text -in cert-aa
    openssl x509 -text -in cert-ab
    ...

philsnow2• 6 years ago

I don't know anything about this company (rootIQ) but it sounds like a juicy, high-value target.

theandrewbailey2• 6 years ago

How so? It looks like this is their only software product, and it doesn't look like they issue certificates.

philsnow2• 6 years ago

If you can compromise the tool that people use to change their certificate stores, then you can sneak in your own root certificates.

egberts12• 6 years ago

The Problem, with distrusting them all Root CAs and accepting it back into the fold one-by-one, is simply that you don’t know if that trusting Root CA in question has signed off some other but malicious sub-CA(s).

falcolas• 6 years ago

How is this worse than the status quo?

egberts12• 6 years ago

Hence the general trend (in the not too far off future) would be to issue an intermediate CA to each website, and even sooner a Root CA for each website.

Not sure if that defeats the purpose of a Root CA, no?

unnouinceput3• 6 years ago

OK, so let's continue this trend and we end-up trusting just one. So we concentrate the entire internet power into just one hand. Because it's such a good idea, right?

gowld2• 6 years ago

Are 2 evil hands better than 1? What's needed are more good hands.

unnouinceput3• 6 years ago

There are no good hands. Governments are slow to catch up but they do eventually. So they did catch up with technology and understanding that internet is freedom. Our freedom was these 25 years we had from 95', when proliferation of internet started up to today. Lockdown even more showed they need tight control over our freedom.

Unfortunately the future is splinternet, where each country has its own grip on this new media medium called internet, same as they do through regulation over TV and radio.

t0astbread• 6 years ago

Well, the situation now is you trust 300 CAs and use one (figuratively). Apart from that, these are root CAs meaning any single one of them could compromise every TLS connection, right? So increasing the number of root CAs doesn't divide their power.

TheRealPomax2• 6 years ago

Why? Just because there is a slippery slope argument to be made doesn't mean we have to actually do what it says needs to be done to get to its theoretical end point.

Sure, we _could_ remove everything until there's one left, but why would we? If you just want a smaller, publicly vetted list of roots that you can trust because the org that curates that set is explicitly on a mission to keep the internet free, open, and safe for all, then there is no "next step", this is the first and also last one.

Is it a good idea to do this? Highly depends on what you do and what you need, but the idea that "we can just keep doing this until there's only one" is super flaky: how many more sets of root certs, vetted by orgs that can be trusted to have privacy and security in mind, are there? Because no org that fits that bill will have a list that is "just the one". There's going to be 100+ certs in their lists.

unnouinceput3• 6 years ago

In case you missed, my comment was a sarcasm

rafaelturk2• 6 years ago

IMG this is lame and can break your system. Also creates a single point of failure if one of this, now super certificates, is revoked

josephcsible2• 6 years ago

What super certificates? What exactly is the new single point of failure?

criddell• 6 years ago

I always wondered how painful it would be to clear out my root store and only re-enable root CAs as I needed them. Would I need more than 5% of them?

rafaelturk2• 6 years ago

For example: redundancy if any of those is revoked, exposed, compromised.

dddddaviddddd• 6 years ago

Experience would probably be similar to using NoScript in a browser. Lots of broken things at first, then tapering off.

proactivesvcs• 6 years ago

I did this in Firefox many years ago and, to a lesser extent, on Windows and Android. Firefox and Windows changes caused minor, obvious problems which I was able to resolve quickly. On Android I found several apps were so badly programmed they simply displayed blank screens, or showed other strange failures, when the required SSL certs were distrusted. Steam, Naver Line and tumblr were the three that I recall fell under this. There were a few apps which immediately threw a human-readable error about certificates, and hence were easier to resolve.

galaxyLogic4• 6 years ago

" Windows trusts 322 root certificates issued by 122 different organizations"

I think this is a good point I would never trust 122 people in my life with my bank-account details. But if I trust my browser it seems that is exactly what I'm doing.

Isn't there a better way?

yRetsyM• 6 years ago

You do trust one company with thousands of employees though, there's layers/levels of trust on this

CodesInChaos• 6 years ago

I don't think the high number of CAs is as big a risk as it sounds like.

1. To exploit this, the attacker needs to be in a man-in-the-middle position and compromise a CA

2. Certificate transparency helps with detecting and banning misbehaving CAs

3. CAs are audited to have processes in place which make it difficult for individuals to misbehave

4. In case of a large scale attack of this kind, banks are relatively likely to refund the money (unlike money stolen by a person you authorized)

5. The individuals employed by CAs are not anonymous and at risk of legal prosecution

I'd be more worried about DNS/registrar level attacks, since CAs generally assume that whoever has control over a domain is authorized to issue certificates for it. I doubt registrars are anywhere near as security conscious as CAs.

And then there is the dependency hell of random software having hundreds of indirect dependencies they didn't verify which are maintained by random, often anonymous people. On most desktop OSs any such application can steal your banking credentials.

galaxyLogic4• 6 years ago

I see there are safeguards in place. But is it true that it is enough to compromise one CA to compromise my browser? Or would a hacker have to compromise ALL of the 322 certificates?

If the latter then having more certificates would simply mean it is more secure. If the former it would mean having more certificates makes it less secure.

Or is it something in between? Do additional certificates add to the security, or diminish from it?

peterwwillis3• 6 years ago

No, to exploit this, you just need to either 1) work inside a CA, 2) be a spy and infiltrate the CA, 3) use your nation-state powers to force a CA in your borders to do what you want, or 4) be a clever hacker hack a CA. There are "only" 330 different complex organizations in probably a hundred-plus countries to try, so I guess this is pretty unlikely.

But even if it is, you can actually hack the entire system with just a BGP hack. Today, if you issue some false BGP routes, you can MITM LetsEncrypt (or one of the other 329 CAs) to sign a valid cert for you. It's not hard because validation is automated and depends on proving you own IP space... and IP space is just what your router's BGP table says it is at the moment you issue a cert.

I would not depend on the kindness of banks giving back money on very large scales. They care about themselves more than they care about you.

You're right, DNS registrar and nameserver attack is another great attack and usually they're pretty vulnerable, so that's another good option.

peterwwillis3• 6 years ago

Isn't there a better way?

There's always a better way. But when you're going up against gigantic incumbents with way more power than everyone else, you don't get the better way. You get the way the powerful decide it will work. It's like politics, or economics. When a system is so large and unwieldy, significant change can't come unless the ridiculously powerful minority forces it. If they have no reason to do so...

DeepYogurt• 6 years ago

I love how the author asks the reader to implicitly distrust the OS vendor, but then also to implicitly trust their random software. Seems legit to me.

hdjfktkrk• 6 years ago

Exactly this. If this was an EFF tool maybe I would trust it.

But a binary hosted on GitHub? Especially since GitHub is whitelisted by major browsers so you would not get a reputational warning when downloading a binary. This is exactly the place where a malware vendor would put it's stuff to avoid scary browser warnings.

Also, privacy tools are perfect targets for intelligence agencies, hackers, ... since they are used by people with something valuable (bitcoin, information, ...) so you need to be extra-careful around them.

ThePadawan• 6 years ago

What browser is this?

Chrome will try its best to not let me download .zip files containing .exe files.

skipants• 6 years ago

In direct contrast to this article, I've had to specifically set `security.enterprise_roots.enabled` to true on Firefox because completely legitimate sites were not trusted.

tialaramex6• 6 years ago

Note that this config flag specifically only applies to the roots installed in your local systems that are not trusted by Microsoft.

So "completely legitimate" these sites may be, but they aren't publicly trusted by anybody, it's just that somebody used Group Policy in your organisation to trust the issuer. So configuring your Firefox to copy other browsers and accept this is fine, but you should go into it eyes open.

josephcsible2• 6 years ago

It sounds like either your antivirus or your company is breaking your SSL.

svnpenn• 6 years ago

So people are just allowed to post ads for closed source software now?

peterwwillis3• 6 years ago

Yes, it's called SaaS, and their "ad-blogs" make up about 20% of all the top stories on HN. Startups that charge you to use their proprietary software but write good clickbait or Show HNs. (I'm not hating, I'm just saying this is not surprising in any way)

unilynx• 6 years ago

fun related certificate fact, TIL that Linkedin's share does not seem to support any of the dutch government certificates - https://www.linkedin.com/post-inspector/inspect/https:%2F%2F...

(I wish they wouldn't bother with all the EV certificates and just accept LetsEncrypt. So much manual work for broken certificates that need to be replaced whenever the CA messes up the trust bits or Iran hacks the certificate providers again)

rswail• 6 years ago

How does this compare to MacOS? I haven't gone through Apple's default CA roots.

Many of the root certificates on Windows are not needed

Related Stories