Incompetent by design: why certificate authorities fail

(And more importantly, why we can not do anything to fix that.)

It sounds like a great business model, one that ought to be advertised on late-night TV infomercials. It might work this way– imagine loud, over enthusiastic pitchman reciting:

“Become a certificate authority! For a few pennies a day, you can sign largely meaningless statements that users around the world depend on to protect their Internet communications. Forget about hard work and all those complicated problems of identity verification. Let your servers figure out the trustworthiness of the customers. And if they get it wrong? Hey, who cares– your certification policy statement indemnifies you from any damages resulting from gross negligence.

And if you call in the next 10 minutes, we will even allow you to issue EV certificates!”

There is an abundance of evidence that certificate authorities are by and large incompetent, clueless and outright bone-headed:

  • Bogus Microsoft code-signing certificate, valid until 2017. (Yes they are revoked but look in your Windows cert store, and under “untrusted certificate” you will see these two shipping in every version of Windows out of the box marked with the equivalent of danger-will-Robinson sign, just in case revocation check failed for some reason.)
  • The real Mozilla: bogus certificate issued for the distribution website of Firefox.
  • Circular dependency on DNS. Dan Kaminksy’s work on DNS vulnerabilities revealed that some certificate authorities verified ownership of a domain simply by sending email to that domain– a security solution designed to be resilient in the face of a completely 0wned network is rooted on the assumption of email routing being trusted?
  • Having an email address with the word “admin” in the tiel does not entitle user to SSL certificates for that domain. This is a lesson email-hosting providers found out the hardware when free email accounts with authoritative-sounding names were enough to convince CAs to issue certificates to the user who squatted on that account name.
  • The crowning achievement: RapidSSL continues to use MD5 for issuing new certificates in 2008– four years after the pioneering work of Xioyung Wang made it clear that MD5 can not be used for new signatures due to possibility of hash collisions. Resulting attack, in spite of being entirely predictable as train wreck in slow motion, is spectacular enough  to earn best-paper at Crypto 2009.

It’s not that every certificate authority is clueless: but the abundance of these examples make it clear that somewhere somone is bound to do something remarkably dumb. That brings us to problem #1:

It takes only one CA to bring down the system. To simplify the picture a bit, operating systems have a set of “trust anchors”– list of the certificate authorities they are willing to trust for important assertions such as the identity of a website they are about to share some personal information with. These anchors are interchangeable. A certificate issued by one is trusted as any other. Any one of them is good enough to show that padlock icon for IE or yellow address-bar for Chrome or … (In an ingenious marketing scheme, a new category called extended validation or EV was created to separate the “competent” CAs from the hoi-polloi. We will address in the second part of this post why EV is a very profitable type of delusion.)

This is a classic case of the weakest link in the chain. Successfully compromising any one CA is enough to defeat the security guarantees offered by the public-key infrastructure (PKI) system they constitute collectively.

Quick peek at the Windows certificate store in XP reveals somewhere north of 100 trusted certificates there. Among these, Verisign and Microsoft are probably the only recognized brands. How many users heard of Starfield Class 2? UserTrust based out of Salt Lake City, Utah? For some international flavor try Skaitmeninio sertifikavimo centras, based in Lithuania. There is also “NO LIABILITY ACCEPTED (c) 97 Verisign Inc”– yes that is the name of the issuer on one of the root certificates. (Complete with all capital words; Verisign could use some help from Danah Boyd on capitalization it appears.)

That list is actually a conservative estimate. Windows has a feature to auto-update new root certificate from Windows Update on demand during chain building. That’s why the sparse appearance of roots in Vista and Windows 7 out-of-the-box is misleading. They are still implicitly trusted, waiting to be triggered during a search for roots. MSFT has a KB article pointing to the full list of current roots. 0wn one of these 100+ entities, and you can mint certificates for any website. 0wn one of the couple dozen trusted for code signing and you can start writing malware “signed” by Microsoft or Google.

What does it take to join this privileged club? It’s not yet being advertised in infomercials but both Microsoft and Mozilla publish the criteria. MSFT being under the scrutiny of regulators is under particular pressure to keep a level playing-field and keep the ranks of membership relatively open. Mozilla has its own requirements to allow low-cost issuers since the open source community generally views PKI as no less than a cabal of rent-seeking oligopoly. (Google Chrome simply picks up the trust-anchors in the platform, namely Windows root from CAPI on Windows and NSS/Mozilla roots on Linux.) In reality since an SSL certificate that only works for some fraction of users is largely worthless, the criteria CAs live up to is the intersection of both programs.

The interchangeable nature of CAs for end-user security brings us to the fundamental economic problem: there is no incentive for better security in a commodity product. CAs are competing on a commodity and market dynamics will drive prices closer towards zero– along with that the quality of the product. If one CA decides to do a better job of verifying customer identity and charge extra for this, customers will simply move on to the next CA who rubber-stamps everything sent its way. Competence is self-defeating.

There is a more subtle economic problem in the model: the paying “customer” is the website or company that needs a digital identity. (or as the examples above demonstrate, the miscreants trying to impersonate the legitimate owner– CA gets paid either way.) But the end-users who depend on that certificate authority doings its job correctly are not privy to the transaction. This externality is not factored into the price.

One could argue the direct customer is on the hook: if a company suffers an attack because of a forged certificate in its name, their own reputation is on the line and this provides economic incentive to do the right thing. But this is deceptive. Even if Alice cares enough about her reputation to shell-out extra $$$ for a high-quality certificate from the most diligent CA, she can not fend off an attack from Mallory who tricks the dirt-cheap and careless certificate authority into issuing a bogus “Alice” identity to Mallory. The existing installed base of web browser does not provide a way for Alice to instruct her current customers to only trust certificates from the competent CA and ignore any other identities. (Even assuming Alice wanted to do this– it would mean creating lock-in for the CA and voluntarily relinquishing the competitive pressure on pricing.)



One thought on “Incompetent by design: why certificate authorities fail

  1. mdatssc says:

    For some international flavor try Skaitmeninio sertifikavimo centras, based in Lithuania…

    hmm.. just confused what is wrong with the Skaitmeninio sertifikavimo centras or you simply don’t like Lithuania? 🙂

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s