Tenuous Chains Of Trust In Digital Certificates

Hot on the heels of RSA suffering an attack of unknown origin and resulting in a loss of unknown data with an unknown impact, news that certificate authority Comodo issued nine fraudulent certificates that browser vendors and OS vendors have had to issue a patch for highlights the fragility of the security systems that protect your data in transit across the Internet. In Comodo's case, neither the root CA nor any of Comodo's systems were compromised, according to its own incident report. Rather, one of its customers, a registration authority, was compromised. It appears the compromise was quickly caught and Comodo started working with vendors to get a fix in place. It's time to once again question whom we trust and why.

Answer this question: Where did the root certificates in your Web browser, computer or mobile device come from, and why do you trust them? It's a question I like to ask my students in the grad course I teach at Syracuse University because there is an inordinate amount of trust in all things SSL/TLS and the Golden Lock. (Don't get me going on that farce called Extended Validation Certificates.) The SSL/TLS protocol and the public key cryptography that underpins it are, as far as I know, well-designed and trustworthy. Barring software vulnerabilities and poorly designed SSL/TLS libraries, such as the Python SSL library's default implicit trust of certificates that Brian Keefer points out in Unauthenticated SSL Sends a Dangerous Message, we can trust the protocol and the math.

No, the trust lies with CAs such as Comodo and Verisign that issue, manage and revoke certificates. Everyone knows the name Verisign. Some may also know Comodo or Thawte (acquired by Verisign in 1999). But there are many, many other players, and the merger and acquisition activity among them is worthy of any shell game on the street. Here's a head scratcher: Who owns and runs the GTE Cybertrust Root CA? GTE hasn't run that CA in more than 11 years. Did you know the GTE Cybertrust CA was acquired by Baltimore Technologies in 2000? Baltimore sold off the CA to BeTrusted Holdings in 2003. BeTrusted and TruSecure merged, forming Cybertrust, in 2004. Cybertrust was then acquired by Verizon business in 2007.

What about some other trusted authorities? If you like football, you probably know who GoDaddy.com is. Did you know it runs a CA? So does the Taiwan Government, as well as Dell. Why would you trust any of them?

I am not saying any of those vendors should or should not be trusted. In fact, I am not saying anything about them at all, really. I am asking why you and your organization would trust them? Have you contacted any of them? Have you negotiated contract terms and signed the papers? Have you ensured that they are running their CA properly and up to your organization's standards? The answer to all of those questions is probably no. You could go read their certification practice statement, which defines how they run their CA and other components. You could also go read their certificate policies, which state the acceptable uses of the certificates, how they are issued and other things. One or the other describe the CA's self-stated role and responsibilities, as well as any redress in the case of a problem with a certificate they issued.

What I am doing is calling to question the very matter of trust on the Internet. The chain of trust between a SSL/TLS-enabled server is tenuous at best, and there are so many points where that trust can be subverted, often without the users' knowledge. A large part of our trust in SSL certificates lies with the certificate authorities and how they run their systems.

In Comodo's case, it discovered the problem on March 15 and on March 22 went public, coinciding with various browser vendors issuing patches to block the use of the certificates. Jacob Applebaum wrote an interesting analysis, Detecting Certificate Authority compromises and web browser collusion, before any of this went public. The analysis is worth a read, as are the comments.

I think Comodo went public in a reasonable amount of time. Shorter is always better, but seven days, I think, is acceptable. What isn't acceptable is why a patch was needed, anyway. Veracode's Chris Wysopal summed it up well: "So because browsers don't all have [Online Certificate Status Protocol] OCSP enabled by default, we need browser updates for the Comodo breach? Isn't that what OCSP is for? When Verisign erroneously issued certs for Microsoft in 2001, they couldn't be checked because there was no CRL distribution point. So Microsoft had to issue a patch to rectify the problem. We can't seem to get revocation right."

But that is a topic for another time.