Armed with these fake SSL certificates, the owner can successfully trick your browser into believing you're logging on to a secure site when you're not, but that's only part of the equation. Someone with a bogus SSL cert would have to redirect your browser. For example, you would type or click on a link to
https://mail.google.com and somehow the bad guys would send you to their own site, offering the bogus mail.google.com cert.
Comodo claims that, because of the redirection, "The perpetrator can only make use of these certificates if it had control of the DNS infrastructure." That doesn't seem, to me, to be the only vector. I'm skeptical.
Apparently on March 15, Comodo notified Google, Microsoft, and the folks at Firefox, telling them that there were nine bogus SSL certificates floating around. You might expect that Google, Microsoft, and Mozilla would simply update the list of revoked certificates, so when their browsers checked to see if the certificate is OK, red lights would go off -- but you'd be wrong.
It's complicated, but the bottom line is that each browser treats SSL certification revocation differently, and there's no way to reliably say, for all browsers, "This particular SSL certificate for
https://mail.google.com is bogus and you shouldn't let the user accept it." Peter Eckersley at the Electronic Frontier Foundation has a detailed analysis of the scheme. He calculates, roughly, that in order to pull down those bogus SSL certificates, Comodo would have had to take out somewhere between 85,000 and 205,000 perfectly legitimate HTTPS sites. Peter's conclusion bears repeating:
What we need is a robust way to cross-check the good work that CAs currently do, to provide defense in depth and ensure (1) that a private key-compromise failure at a major CA does not lead to an Internet-wide cryptography meltdown and (2) that our software does not need to trust all of the CAs, for everything, all of the time.
Instead of refreshing a simple list, all three browser manufacturers pushed updates to the browsers themselves. Google updated Chrome on March 16, according to the Tor Project's blog. Mozilla updated Firefox 4.0, 3.6, and 3.5 by March 22, per a note on the Mozilla Security Blog; I've also heard that Firefox 4.0 was sent into its second Release Candidate specifically because of this problem. Microsoft issued Security Advisory 2524375 on March 23, which announces a "mitigation" patch to Internet Explorer that will be rolled out shortly.
So maybe the Iranian government was fishing for SSL certs; maybe not. There's lots of conjecture about why someone would want those certs and what they could do with them. The "control of the DNS infrastructure" prerequisite Comodo mentions points to a governmental group, but that doesn't appear to me to be the only possible way of using the certs -- fair enough.
Let's not forget what got us here in the first place: Comodo's culpability speaks volumes, and there's something fundamentally wrong with the trusted certification system as a whole.
This article, "Weaknesses in SSL certification exposed by Comodo security breach," was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest business technology news, follow InfoWorld.com on Twitter.