Are Some Certificate Authorities Too Big To Fail?

In the wake of this weekend’s revelations of the seriousness of the attack on certificate authority DigiNotar, security experts have renewed criticism of the Internet’s digital certificate infrastructure, with some wondering if larger certificate authorities (CAs) might be too big to fail.

Rob LemosIn the wake of this weekend’s revelations of the seriousness of the attack on certificate authority DigiNotar, security experts have renewed criticism of the Internet’s digital certificate infrastructure, with some wondering if larger certificate authorities (CAs) might be too big to fail.

DigiNotar’s network had significant security weaknesses that allowed an attacker to issue an unknown number of untraceable certificates, a report by Dutch security firm Fox-IT found. The situation has led the Dutch government to take over operations of the CA, and major browser vendors to patch their products, breaking the trust their software has of secure-sockets layer (SSL) certificates issued by DigiNotar.

Revoking Diginotar’s authority was necessary because the company failed to secure its infrastructure, allowing an unknown number of certificates to be created, says Moxie Marlinspike, chief technology officer of startup mobile security firm Whisper Systems. The result will likely be that DigiNotar will not survive as a certificate authority.

“It’s not a simple matter of removing certificates from a database, because they’re not in any databases,” says Marlinspike, who presented an alternative approach to the current SSL infrastructure last month at DEFCON. “We may never track them all down.”

While revoking trust in Diginotar may help bring that crisis to a close, Marlinspike is among a large number of security researchers who worry that larger firms such as Comodo or VeriSign may likewise be vulnerable.  Unlike Diginotar, those  larger certificate authorities may be “too big to fail” – forcing browser makers to keep them on their lists of trusted issuers out of fear of the disruption that blacklisting them would cause.

In March, certificate authority Comodo acknowledged that an attacker had been able to issue at least nine certificates for major domains, such as Google and Yahoo. However, because of the limited nature of the breach, browser makers decided only to revoke the fraudulent certificates.

Yet it is unclear whether a more significant breach would have resulted in Comodo losing its authority, says Peter Gutmann, a researcher in computer science at the University of Auckland.

“Once you’ve issued enough (certificates), the browser vendors won’t pull your CA cert any more because it would affect too many people,” Gutmann says. “This is what saved Comodo. In Diginotar’s case they were small enough that the browser vendors could pull their certs.”

Mozilla justified its decision to rescind trust in DigiNotar by noting that the extent of the breach is still unknown, that DigiNotar failed to notify the public in a timely manner, and that attacks using the certificates have been document in the wild, Johnathan Nightingale, Director of Firefox Engineering, stated in a post on Friday.

“The integrity of the SSL system cannot be maintained in secrecy,” Nightingale wrote. “Incidents like this one demonstrate the need for active, immediate and comprehensive communication between CAs and software vendors to keep our collective users safe online.”

Comodo argues that it avoided that kind of “worst case” scenario because it had a diverse set of defenses in place to limit the breach.

As certificate authorities grow, so does their responsibility to provide better security. “Larger CAs should have more resources for monitoring, detecting and reacting quickly to these kind of attacks,” said Melih Abdulhayoglu, CEO of Comodo. “If you remember Comodo reacted within minutes and provided transparency to the world in a timely manner.”

Security researchers, however, argue that the best defense against a breach at a certificate authority is for browser makers to find other ways to ensure online safety. 

“I might say that concentrating all risk in a single, failure-prone mechanism that has been shown to have zero effect in stopping the bad guys  is a really, really bad idea,” says the University of Auckland’s Gutmann.

Part of the problem is that attacks on third-party trust providers  such as Comodo, RSA and DigiNotar are a new trend, says Jeff Hudson, CEO of Venafi, a maker of certificate management software.  As security professionals focus on the problem, better policies will be put in place that will mitigate the threat of a major breach at a large CA.

Rather than place total trust in a CA, for example, users in the future might be able to decide who to trust or have a sliding scale of risk. A valid certificate, brand-name domain and valid domain-name record would be positive factors. A certificate issued by a compromised CA, for example, a suspicious DNS record, or just-issued certificate would be negative factors.

For now, however, companies that rely on SSL certificates for their business need to be prepared for the worst, Hudson says.

“Right now, the state of preparedness for failure is dismal,” he says. “People have to recognize this and be ready. You have to know who your trust providers are, where you assets are, and be ready to swap out a provider’s certificates in hours.”

Suggested articles


  • sandhu on

    The issue with lax security at CAs isn't the root cause, it is a symptom. It is a symptom of no one paying attention to security or security always as a bolt-on. A new architecture won't solve anything.

  • Anonymous on

    I disagree with sandhu, regarding that a new architecture won't solve anything.

    A new distributed architecture where more parties than just one CA key is needed to authorise a proper signing might be a better way to go.  Where more than one CA is actually doing the signinig.  If you need, say three parties, to sign a CSR, and with some control mechanisms to make sure they are independent from each other should be able to solve this issue.

    However, in todays world where everyone wants everything automised with instant signing in 10 minutes, that will *always* be vulnerable for such attacks.  It is about time that the CA industry accepts that some routines needs to take a day or two, so that proper controls can be implemented and with possibility for more CAs to control each other.

    But I'm afraid such scenarios might require changes of the SSL/TLS protocol, to avoid other ways to raise the bar of simplifying and automating such jobs.

  • Harry Johnston on

    For the price CAs charge, you'd think they could keep their certificate keys on machines isolated from the internet, with full logging and a real person making the final decision to approve signing a particular key.

  • Eric Dorman on

    It's the CAs responsibility to make sure that the certificates that they issue are valid and provide the right info. Browser vendors are not to be blamed to this problem because all of the security of making sure these certificates that get issued fall on the hands of CAs. If CAs secure their networks and provide new security technology to help mitigate these attacks then the certificates will not be fake.

  • Anonymous on

    Contrary to what you are alleging above, the dutch government has not taken over operations of DigiNotar. They kicked them out as preferred CA, and are now forced to replace all certs in use issued by DigiNotar.

  • Anonymous on

    How ironic that attempting to view this very post over https gives an error if you have OCSP revocation checking enabled. (SEC_ERROR_OCSP_INVALID_SIGNING_CERT -8048 "Invalid OCSP signing certificate in OCSP response.", see
  • David on

    I am truly terrified by the prospect of "and be ready to swap out a provider's certificates in hours.".

    If there is need to swap out providers that quickly, I can all but guarantee allot of checks will be bypassed in the intrest of uptime. Godaddy did not need to ask me allot of information about the certificate because I registered the domain with them. Another provider will have to put me through the full cycle which can take days to weeks, depending on the type of certificate.

    The obvious counter is that I need to guess which providers won't be hacked and pre-aquire certificates so I have a spare if my primary gets compromized.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.