Weaknesses in SSL certification exposed by Comodo security breach

Comodo Group paints itself as a victim in the case of the hijacked SSL certificates, claiming to be duped by the government of Iran into releasing electronic certificates that would allow the country’s regime to snoop on its citizens. That’s only part of the tale. The whole story involves a company that simply didn’t do its job, betrayed our trust, and tried to excuse its incompetence by blaming a bigger villain. It also exposes a system of “trust” that’s proven itself untrustworthy.

While the press has focused on the sensational fact that Comodo’s site was hacked from an Iranian IP address — and one of the bogus SSL certificates was used on an Iranian site for a short period of time — we really should be asking three questions:

1. How did somebody working with an Iranian IP address get a username and password from Comodo with enough clearance to create SSL certificates?
2. Why did Comodo issue SSL certificates for google.com, live.com, yahoo.com, mozilla.org, and skype.com? Isn’t anybody watching?
3. Why are browser updates used to revoke SSL certificates? That’s preposterous.

To understand these issues, you need a bit of background on how certificates work. When you go to an HTTPS address, your browser encrypts communication with the site. The mechanics of setting up the connection involve public key cryptography; your browser and the website have to implement the encryption by exchanging public keys. Your browser also has to determine that the public key it receives is valid, which is where the certificate comes into play.

A certification authority issues digital certificates that say, in effect, “This is the public key owned by XYZ Corp.” If you point your browser at https://xyzcorp.com, the website sends your browser a public key and its certificate. Your browser verifies that the certificate was issued by a “trusted” certification authority, is associated with the site you’re looking at, and is still valid. It performs this check by looking to see if the specific certificate is on a list of revoked certificates. If all passes muster, your browser uses the public key to initiate an encrypted session with the HTTPS website.

Certification authority companies charge money to issue certificates, and websites apply to get a certificate. Meanwhile, browsers maintain lists of validated CAs, which could run to several dozen companies. I trust — and you trust — those companies to make sure a certificate for XYZ’s website gets issued to only XYZ Corp. The three largest certification authorities are VeriSign, GoDaddy, and Comodo.

As Gregg Keizer reported on Computerworld yesterday, somebody used a valid username and password to get into the Comodo certificate issuing system. The cracker set up a new user account and issued nine validated requests (called “certificate signing requests”) to apply for certificates. Certificates were then issued by Comodo to the interloper for mail.google.com, login.live.com, www.google.com, login.yahoo.com (which received three separate certificates), login.skype.com, and addons.mozilla.org, as well as one not associated with a specific URL, validating “global trustee.” There are no details — at least none I can track down — about how that person managed to get the username and password.

More troubling, I can’t find any indication that anyone is monitoring the issuance of certificates. How on earth could Comodo issue an SSL certificate for mail.google.com, without somebody, somewhere hitting the ceiling?

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.