27

After two recent Slashdot articles (#1 #2) about questionable Root Certificates installed on machines, I decided to take a closer look at what I have installed on my machines.
(I use current versions of Chrome on Win7, which I understand uses the Windows list of CAs)

What I found really surprised me.

  • Two relatively clean machines had vastly different lists of CAs.
  • Each had a number of CAs that had expired in 1999 and 2004!
  • The identity of many of the CAs is not easy to understand.

I also saw that many certificates expire in 2037, shortly before the UNIX-rollover, presumably to avoid any currently unknown Y2K38-type bugs. But other certs are good for much longer.

I searched around, but, somewhat surprisingly, couldn't find a canonical list of which CAs are generally accepted.

  • If I had a MITM rogue cert on my machine, how would I even know?
  • Does a list of "accepted" certs exist?
  • Am I safe in removing the expired CAs?
  • Can I know if/when I have ever used a CA for HTTPS?
abelenky
  • 373
  • 1
  • 3
  • 8

4 Answers4

20

All or None.

The singly-rooted CA trust paradigm we inherited from the 90s is almost entirely broken.

Vanilla browsers do not track or alert if the Certificate Authority backing a SSL certificate of site has changed, if the old and new CA are both recognised by the browser1. As the average computer trusts over a hundred root certificates from several dozen organisations2 - all of which are treated equal - any single breached, lazy or immoral certificate authority can undermine any browser anywhere.

The problem is compounded by the fact that almost all of the certificate authorities are not democratically accountable to you (i.e. private companies or foreign governments) and have little or no legally-enforced regulation over their day-to-day conduct. Maintainers of CA lists (Microsoft, Apple, Google, Mozilla, Oracle, etc) do not have the resources, legal authority, or inclination to audit the internal conduct of certificate authorities.

The epistemological riddle of who and what are we actually trusting, that was introduced by a 1990s Netscape trust kludge3, will require an expensive overhaul to resolve. Which I don't see happening this side of an threatened or actual cyberwar.

So.

  • If your computer (say, a server) doesn't talk out to unknown or ad-hoc sources - then run your HTTPS traffic through a proxy with an explicit list of trusted leaf-node certificates and no root certificates.
  • For normal computers which browse the internet and update dozens of applications in the background, just trust all of them and follow other security principles to protect your computer instead.

1. Back-end services and frameworks couldn't usefully prompt on change anyway; as they often lack interaction with the user and need to provide seamless operation.
2. See Firefox or iOS CA lists for example.
3. Try as I might, I couldn't re-locate a fascinating web article about how Netscape developers introduced the current Root CA paradigm as quick patch for theorised Man-in-the-Middle attacks for as-yet hypothetical eCommerce. Digital security is hard; and the cold war hangovers and legislative techno-illiteracy of the early 90s didn't help.

LateralFractal
  • 5,173
  • 18
  • 41
8

Looking at it from a risk and probability perspective, you could trust each single one of them individualy, but you can't trust all of them collectively. If you were to have 100 CA's and each one has a 98% probability that they could be trusted, you'll end up with a 13% probability that you could trust the lot of them ( 1 -(1-p)^N ).

Browser vendors could easily fix the problem by providing a certificate info API to plug-ins b.t.w. There is one tell tail sign of MITM attacks on SSL: premature certificate changes with an unrelated CA. If browser vendors were to allow plug-ins to detect these, the trust level for CA based security would go up significantly.

user1703394
  • 311
  • 1
  • 4
4

The other answers are full of wisdom.

I just wanted to point out the Firefox extension called Cert Patrol. It doesn't solve the trust problem, but it does help detect discrepancies between certificates.

The bottom line is, your browser may trust a lot of CAs but you don't have to: if you see a certificate "update" that looks fishy, turn around before you enter any password.

Also, someone has to link to Honest Achmed's root certificate request. It is an hilarious, albeit sad comment about the CA ecosystem as it is right now.

executifs
  • 4,792
  • 4
  • 24
  • 25
  • I used to use the _Certificate Patrol_ plugin, but I found I had to spend a lot of my time micromanaging it. The problem is that a lot of load balanced SSL server farms; advertising networks and indirection services rely on our broken interchangeable CAs to work seamlessly. The current TLSv3 protocol simply doesn't provide the metadata for coherent trust handover decisions to be made. For example, new certificates aren't linked/signed against the previous; nor are we using [government-level CAs](http://security.stackexchange.com/a/43877/30521). Honest Achmed's is hilarious. – LateralFractal Mar 11 '14 at 10:14
  • I concur: Certificate Patrol does require a lot of manual fine-tuning. Is it worth the effort? I guess I'll know the day it actually saves my day, if it ever comes. – executifs Mar 11 '14 at 10:27
2

You can certainly remove the expired certificates, and really any from any CA you don't know or don't personally trust. The primary effect would be that if you surf to a site that had been authenticated by one of the certificates you removed, your browser will not trust the site.

If you remove a certificate that signs software updates, particularly those of any extensions you've installed in chrome, those updates will fail.

AFAIK there is no 100% universally agreed-upon list of CAs. Browser vendors and OS vendors make their own decisions about which root certificates to trust; some of those may be based more on marketing than actual trust.

John Deters
  • 33,897
  • 3
  • 58
  • 112