A Web of (Mis)Trust – Comodogate Part II

Since we posted about the compromised CA incident and related browser fixes, the incident has been labeled “Comodogate”. Quite a bit of information has been released since then. There is even a voice that claimed responsibility for the breach, allegedly describing his attack and proving his success by disclosing a private key.

The CEO of Comodo (the Certificate Authority compromised in this incident) stirred an alphabet soup of speculation regarding attribution, or who may have performed the break-in and their motivations. At one point, he even compared the recent RSA incident as related, claiming the entire authentication layer of the internet is under attack. While the RSA-gate incident may seem to be coming from another, yet connected, part of the world, it was another attack on the trust inherent in authentication and cryptography services. There is more than a kernel of truth to the statement.

It is easy to say that authentication services are under attack across the internet. It’s a lot like saying the browser is under attack in a flash of the obvious.

The voice that came forward and claimed responsibility for the attack and certificate theft posted the actual private key for one of the stolen certificates. It was data (outside of the CA and the true developers) only the thief could possess. You can verify the key yourself by following these instructions. He has done faceless interviews, he has assumed a twitter account and replied to all sorts of questions and tweets.

The author(s) is actively talking about his self. It’s interesting reading the text from this voice, because its author is allegedly a source of the breakdown of the fundamental trust of authentication and trust on the internet as we know it. The voice comes across as though the reader should trust the character behind it. Can interested parties trust that this individual is *just* a 21 year old student as they claim? Why would you?

At the same time, it’s great to see the Mozilla team interested in improving the use of certificates in their own code. A full response to the Comodo incident is being maintained, involving HSTS, OCSP, TOFU, and perhaps all-too-late DNSSEC enforcement, along with enhancement comments about PKI.

Considering that researchers like Moxie Marlinspike have demonstrated effective MITM attacks on SSL a couple of years ago in very public forums, one would think that browser developers would have taken SSL threats more seriously. Is there a reason or real need to hardcode denylisted SSL certificates into browser code at this point? How safe does that make you feel?

Updated information on Certificate Authority and Root Authority policies is here, much of which does not seem to have been respected within the Comodo relationship with their vulnerable Italian affiliate (GlobalTrust.it and InstantSSL.it), whose account is now suspended. Hopefully the discussion takes the actual level of SSL related security to an improved state. Trusted communications cannot be based on a broken implementation like this one.

Update (4/1/2011): Ben Laurie weighs in on the discussion with thoughts on two initiatives to help improve the PKI. The second of the two is more open and seems much more valuable, but a much longer term project.

1. Google Certificate Catalog – “Google’s web crawlers scan the web on a regular basis in order to provide our search and other services. In the process, we also keep a record of all the SSL certificates we see. The Google Certificate Catalog is a database of all of those certificates, published in DNS”. Users currently need to know all sorts of technical detail, and due to the complexity of use here, it won’t be adopted by the masses anytime soon. Bundling it into a Chrome add-on would definitely help, similar to the existing Perspectives project and Firefox add-on.
2. the IETF DANE Working Group – this initiative is related to and dependent on an infrastructure that properly implements DNSSEC, which is a long way off. Interesting stuff that would be very valuable, but will move slowly: “In short, the idea is to allow domain operators to publish information about SSL certificates used on their hosts. It should be possible, using DANE DNS records, to specify particular certificates which are valid, or CAs that are allowed to sign certificates for those hosts.”