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:
- How did somebody working with an Iranian IP address get a username and password from Comodo with enough clearance to create SSL certificates?
- Why did Comodo issue SSL certificates for google.com, live.com, yahoo.com, mozilla.org, and skype.com? Isn't anybody watching?
- Why are browser updates used to revoke SSL certificates? That's preposterous.
[ Master your security with InfoWorld's interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]
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?