How feasible is it for a CA to be hacked? Which default trusted root certificates should I remove?

Question

This question has been revised & clarified significantly since the original version.

If we look at each trusted certificate in my Trusted Root store, how much should I trust them?

What factors should be taken into consideration when I evaluate the trust of each Root CA for potential removal from my local store?

More Information:
If a CA issues a certificate to an improperly validated party, then that causes all machines that trust that CA vulnerable to MITM attacks. As a result all CA's stringently validate the requester of a given SSL certificate request to ensure the integrity of their CS chain.

However, a large part of this CA verification process is subject to human intervention and provides opportunities to issue a cert to the wrong party. This may be done by CA operator error, government demands, or perhaps the coercion (bribe) of a CA operator.

I'd like to learn more about which default CA's are more likely to issue certificates to the wrong party. I intend to use this information to advise users to remove that CA from their Trusted Cert Store

Examples:
Suppose the government controlling a particular CA wants to assume the identity of Microsoft.com, and demands an exception to the CA's verification process. That government then also requires the secrecy of this exception be maintained. The generated key pair would then be used in a MITM attack.

Windows Azure Default Trust

Windows Azure supports 275 CA's as shown in the following link. Depending on the use of the particular CA, some of those CA's may increase the surface area of a particular attack. In fact this may be technically required to make some applications work correctly.

Amazon Default Trust

(not available) Please share links to Amazon, Google, and VMWare's default CA list if you come across them.

Mozilla

A list of all certificates and audit statements is available.

Apple iPhone

List of all iPhone root certificates

Answer 1

Update 5 The root problem (heh) with the CA model is that in general practice, any CA can issue certs for any domain, so you're vulnerable to the weakest link. As to who you can trust, I doubt that the list is very long at all, since the stakes are high and security is hard. I recommend Christopher Soghoian's post on the subject, which clarifies the various approaches that governments around the world have used to get access to private user data - whether by directly demanding it from companies that operate cloud services, via wiretap, or increasingly now via CA coercion or hacks: slight paranoia: The forces that led to the DigiNotar hack.

Here I provide some specifics, and end with links to some potential fixes.

In 2009, Etisalat (60% owned by the United Arab Emirates government), rolled out an innocuous looking BlackBerry patch that inserted spyware into RIM devices, enabling monitoring of e-mail, so it can hardly be considered trustworthy. But it is in a lot of trusted CA lists: http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

Update 1 See also an example of a successful attack, allegedly by an Iranian named ComodoHacker, against Comodo: Rogue SSL certificates ("case comodogate") - F-Secure Weblog. F-Secure notes that Mozilla includes certificates issued by CAs in China, Israel, Bermuda, South Africa, Estonia, Romania, Slovakia, Spain, Norway, Colombia, France, Taiwan, UK, The Netherlands, Turkey, USA, Hong Kong, Japan, Hungary, Germany and Switzerland.

Tunisia is another country that runs a widely-trusted CA, and there is also good documentation of the actions of their government to invade privacy: The Inside Story of How Facebook Responded to Tunisian Hacks - Alexis Madrigal - Technology - The Atlantic

Mozilla notes another questionable practice to watch out for: CAs that allow an RA partner to issue certs directly off the root, rather than via an intermediary: Comodo Certificate Issue – Follow Up at Mozilla Security Blog.
See also more detail, including speculation about the claim of responsibility by a lone Iranian hacker Web Browsers and Comodo Disclose A Successful Certificate Authority Attack, Perhaps From Iran | Freedom to Tinker

Update 3: Another successful attack seemingly also by ComodoHacker was against the DigiNotar CA. Their website was compromised starting in 2009, but this was not noticed until after DigiNotar had also been used in 2011 by Iranians to sign false certificates for the websites of Google, Yahoo!, Mozilla, WordPress and The Tor Project. DigiNotar did not reveal its knowledge of the intrusion into its site for over a month. See more at DigiNotar Hack Highlights the Critical Failures of our SSL Web Security Model | Freedom to Tinker.

I'd guess that the range of vulnerability of various CAs varies pretty widely, as does their utility. So I'd suggest refocusing your strategy. When you can narrow it to specific assets you're trying to protect, just delete all CAs except those necessary for using those assets. Otherwise, consider eliminating the CAs you judge to be most vulnerable to those who care about your assets, or least popular, just to reduce the attack surface. But accept the fact that you'll remain vulnerable to sophisticated attacks even against the most popular and careful CAs.

Update 2: There is a great post on fixing our dangerous CA infrastructure at Freedom to Tinker: Building a better CA infrastructure

It talks about these innovations:

• ImperialViolet - DNSSEC and TLS

• Network Notary - Perspectives : Improving SSH-style Host Authentication with Multi-path Network Probing

• Google Online Security Blog: Improving SSL certificate security

Update 4 One of our IT Security blog posts in August 2011 also covers the case for moving to DNSSEC: A Risk-Based Look at Fixing the Certificate Authority Problem « Stack Exchange Security Blog

Answer 2

As Matt Blaze once wrote, CAs protect you from anyone who they are unwilling to take money from. That should tell you something about where the CA's incentives lie, and some potential risks in the arrangement.

Answer 3

I'm afraid that the short answer to this question is that it's impossible to know, as far as I can see. There are a large number of default CA's installed in most common browsers and assessing how likely they are to be "trustworthy" in terms of giving out certificates to governmental or other organisation is difficult.

If a CA became known as untrustworthy then they would likely be removed from browsers default installation lists, (per @xce below, Diginotar is a good example here and also Digicert)

In addition to the organisation providing certificates voluntarily, there's the risk that they may provide certificates without making appropriate security checks on the requestor. At Defcon a couple of years back there were several presentations on this theme of being able to get certificates without authorisation.

If this is a significant concern, the only way I can think of to go would be to create a white-list of CAs that you've reviewed and are comfortable with the security provided. Obviously this wouldn't work for accessing the general Internet as you'd likely end up removing CAs who have issues Certs to sites that you'd like to use.

Answer 4

2 examples that go to the heart of what you need to know, but not what you're explicitly asking:

• Several years ago (2006, or maybe end of 2005) there was pretty-well publicized incident of SSL phishing - a bogus bank website received a legitimate SSL cert (from GeoTrust, I believe), for a misspelling of a regional bank's site. (Update: found this historic link - the address was for the bank's full name instead of the shortened acronym). Since then, there have been other cases of SSL phishing.... Point is it's possible to get a cert without resorting to "coercion".
• The recent Stuxnet novella relied on, amongst other tactics, stolen certificates. These were "borrowed" from 3rd party driver manufacturers, and since they were "trusted", were able to be misused in order to plant the malware.

Then of course, there are the software scenarios where the CA is not even called into use - e.g. with thick clients that call Web Services, that don't bother validating the server's cert....

My point is that if you're worried about MITM over SSL, more often than not, it's not the governmental coercion that should worry you. There are usually easier and more accessible ways.
I even object to "Trusted Certs" being called "Trusted"... Just because I know who you are, doesnt mean I should trust you... and it doesnt mean I should trust that you know who someone else is.

Not to mention, that if you remove standard root certs from the trusted store, many sites across the internet won't work as expected.

On the other hand, if you're dealing with a server/appliance that does not need general browsing capabilities, but is communicating with a specific server (or set of servers), definitely remove ALL root certs, except a whitelist of the ones you need.
And if you go with your own internal CA, even better....

Answer 5

Every CA publishes a Certificate Practice Statement that describes how they protect their own keys, and validate requests for certificates before issuing them. A URL to the location for this document is usually embedded in each certificate issued by the CA. Assuming that the CA in question actually follows this policy document, it should give you an indication of the lengths they go to to ascertain the validity of the entity requesting certificates. Look for statements to the effect that they protect their CA signing keys using Hardware Security Modules or Cryptographic Modules to protect the signing keys, multi-factor authentication and quorum based authorization to sign certificates, etc. These protection methods make it much harder and more expensive for a rogue third party to steal the signing keys.

The huge list of trusted CAs (my Mac System Roots Keychain has 175) is there for your convenience, to make the HTTPS system usable for you and everyone on the planet who is not asking these questions. You could, of course, kick every CA out of this list unless you have personally audited their practices. For a closed system, where you control all the endpoints and you have a limited number of trusted parties, this is doable. The Subversion version control system does not include any trusted Root certificates, but you are welcome to add your own to every client. For the web at large, the only way we have found to make it usable is to have an out-of-band trusted party (the company that supplies your operating system or browser, whatever you may think of them) supply a list of trusted certificates that enable you to connect to pretty much any SSL-enabled server in the world.

Do you really need all of those certificates in your trusted list? Probably not. But your OS/browser vendor can't anticipate (and shouldn't control) who you want to do business with, so they include 'em all. The problem with the large list is that you have CAs of all plumage, with all kinds of verification methods, from all jurisdictions, treated exactly the same. Not every CA acts the same: we have seen cases of compromised reseller login credentials, and even compromised CA keys. Some CAs require a certificate of incorporation and the promise of your firstborn, others just verify that you can receive e-mail on the domain for which you are requesting a cert. And yet each CA is treated exactly the same by your browser.

A line of defense against rogue certificates for the same Common Name would be to cache the original certificate on the client: if a different certificate from a different CA suddenly shows up, this should be cause for concern. I don't know how today's browsers treat this case, and I'm too lazy to find out.

Answer 6

Suppose some bad government wanted to see the SSL traffic of machines. How feasible is it for the default CA's to be coerced into issuing a new certificate?

The predicate and the question are unrelated. It doesn't matter how easy or often a CA could be coerced into issuing a new certificate - the would-be eavesdropper could not see your data unless they have the private key from the certificate you've already got installed. IIRC (but I'd recommend checking this) the CSR does not include the private key - so the CA can't get it that way. They can't change what keys your machines are using.

However it is possible that a rogue CA might issue a forged certificate - and the potential then exists for a MITM attack on your site. Recent issues with the MD5 format and Etisalat suggest that its not impossible.

Answer 7

I believe the US government tried to pass legislation a few years back giving them the right to force a CA to generate a valid certificate of a 3rd party for wiretapping and what-not. I couldn't find evidence of this, so I may be remembering something along the lines of the DefCon talks Rory mentioned.

Answer 8

This kind of discussion always reminds me of this Mozilla bug requesting inclusion of a new CA. Pretty hilarious, but pretty insightful.

Answer 9

When researching which certificate to remove in a Windows PC, you should first make sure you don't remove system-required certificates. If you attempt to do so you will get the following error message

This is the URL with a list of certs that must never be deleted from a windows system http://support.microsoft.com/?id=293781

Next you should consider removing (testing the removal of) Intermediate certificates, since they only exist "purely for legacy reasons".

When evaluating the removal of all the remaining certificates, consider that the Microsoft Root Certificate Program requires the CA to pass one of these audit standards:

• ETSI 102 042
• ETSI 101 456
• WebTrust for CAs
• WebTrust EV Readiness audits
• ISO 21188 ( Note they do not accept ISO 27001 )

If you're removing Certs from a non MSFT browser (IE) then you may want to review these CA quality guidelines.

Restrictions

The program also has additional audits that apply to what the Key Usage is. Key usage is limited to the following:

• Server Authentication (SSL) =1.3.6.1.5.5.7.3.1

• Client Authentication (SSL) =1.3.6.1.5.5.7.3.2

• Secure E-mail (SMIME) EKU=1.3.6.1.5.5.7.3.4

• Code Signing EKU=1.3.6.1.5.5.7.3.3

• Time stamping EKU=1.3.6.1.5.5.7.3.8

• OCSP EKU=1.3.6.1.5.5.7.3.9

• Encrypting File System EKU=1.3.6.1.4.1.311.10.3.4

• IPSec (Tunnel, User) EKU=1.3.6.1.5.5.7.3.6, 1.3.6.1.5.5.7.3.7

Banned Key Usages

The following Key usages are banned by the program:

• Smart card logon This is an enterprise only scenario, because Active Directory deployment is required and the root must be added to the NTAuth store in Active Directory. See the following KB article for details. http://support.microsoft.com/default.aspx?scid=kb;en-us;Q281245

• Digital rights This EKU is obsolete. Windows Media DRM uses it own XML format for licenses and does not use X.509.

• Qualified subordination This EKU is obsolete and is ignored by Windows.

• Key recovery Enterprise CA scenario.

• File recovery This EKU is obsolete and is ignored by the Windows Encrypting File System (EFS).

• All application policies We cannot grant “all usages” since this necessarily admits enterprise-only and other unacceptable EKUs.

• Directory service email replication Enterprise scenario

• Certificate request agent

• Enterprise CA scenario

• Key recovery agent Enterprise CA scenario

• CA encryption certificate

• Enterprise CA scenario

Acceptance Criteria

In addition following criteria must be met before adding a general purpose or Government CA to the root:

1. The CA must provide the information requested below (see Step 1. Contact Microsoft), and receive preliminary approval for membership in the Program.

2. The CA must provide a test certificate issued from the CA’s root certificate for testing purposes. Optionally, a CA can provide to Microsoft a URL of a publicly accessible server where certificates issued from their root certificate can be verified. (See FAQ for details)

3. The CA must complete a Microsoft CA Agreement. The agreement will be provided only after you have completed Step 1 of the application process and received preliminary approval of your application.

4. Root certificates must comply with the Technical Requirements section below. In particular, we require a minimum crypto key size of RSA 2048-bit modulus for any root and all issuing CAs. Microsoft will no longer accept root certificates with RSA 1024-bit modulus of any expiration. We prefer that new roots are valid for at least 8 years from date of submission but expire before the year 2030, especially if they have a 2048-bit RSA modulus.

5. Certificates issued from a root certificate must support the CRL distribution point extension. The CRL distribution point should point to a location that is publicly accessible.

6. The CA must have a documented revocation policy, and the CA should be able to revoke any certificate they issue.

7. The CA must complete an audit and submit audit results to Microsoft every twelve (12) months. The Audit must cover the full PKI hierarchy that will be enabled by Microsoft through the assignment of Extended Key Usages (EKUs). All certificate usages that we enable must be audited periodically. The audit report must document the full scope of the PKI hierarchy including any sub-CA that issues a specific type of certificate covered by an audit. Eligible audits include:

   • WebTrust for Certificate Authorities v1.0 or later, completed by a licensed WebTrust for CAs auditor,

   • ETSI TS 101 456 v1.2.1 or later,

   • ETSI TS 102 042 V1.1.1 or later, or

   • ISO 21188:2006, “Public key infrastructure for financial services -- Practices and policy framework,” completed by either a licensed WebTrust for CAs auditor, or an audit authority operating according to the laws and policies for assessors in the same jurisdiction as the CA.

These are the accepted audits at this time for non-government CAs. We reserve the right to change the audits listed above and/or accept other comparable audits in the future.

Technical Requirements

New root certificates must meet the following technical requirements:

• Root certificates must be x.509 v3 certificates.

• Subject Name must contain a meaningful name of the CA (ex. cannot be “Root” or “CA1”)

• Basic Constraints extension: cA=true

• Key Usage (if present): keyCertSign and cRLSign only

• Root Key Sizes requirements are based on NIST SP 800-57:

       RSA greater or equal to 2048-bit modulus
  
       ECC greater or equal to P256 modulus
  

• Hash algorithm must be at least SHA1. No MD2, MD4 or MD5 hashes accepted.

• For a root key size of greater or equal to an RSA 2048-bit modulus, root certificate must not expire until at least 8 years after submission and no later than 2030. Longer expiration may be afforded to larger root key sizes.

• Intermediate CA certificates are excluded from the Root CA Program (See Frequently Asked Questions for more information)

• The CA will not issue MD2, MD4 or MD5 subordinate or end-entity certificates from any root certificate distributed by the Program, effective January 15, 2009.

• Existing (“legacy”) 1024-bit RSA root certificates may remain in distribution by the Program until the NIST deadline of December 31, 2010, except as provided by Microsoft.

• The CA may issue 1024-bit RSA certificates from root certificates distributed by the Program until the NIST deadline of December 31, 2010.

Answer 10

Demonstration of creating a rogue CA using MD5 weaknesses:

• Original research
• Press coverage

Answer 11

As of June 12, 2012 Microsoft released a new updater that will disable untrusted root certificates and any other certificate that is reported to Microsoft as untrustworthy.

The update is available here, and I'm unclear if this update has already been distributed through Windows Updates, or if it is an out of band update.

http://support.microsoft.com/kb/2677070