Comodo Issues Nine Fraudulent, High Value Certificates

Peter Bright posted a terrific piece over at Ars Technica describing the fraudulent issuance of nine high value SSL certificates by Comodo. This included such top level domain certificates as www.google.com, login.yahoo.com and login.skype.com and addons.mozilla.org. Other equally good reads are the Tor site detection of the problem and Comodo’s explanation. I’m sure Comodo’s CEO, Melih Abdulhayoglu, is having fun this week.

The case reveals the instrinsic problems with PKI that we’ve all been aware of for a long time.

I am a bit surprised by a couple of things, though suprised is perhaps too strong a word. The first is that a Registration Authority (RA) account could have been compromised for what appears to be a top level certificate. I’m sure this account was well protected, and it’s true we don’t yet know the nature of the compromise, but I had somehow imagined that on-site access would be required, or multiple approvals if the RA user was off-site. This is a somewhat silly expectation, given that SSL certs go for $50, a price which dictates a certain level of process automation. I guess I would have been less surprised with flaws in the vetting process then flaws with RA account authentication.

The second surprise is with how browsers treat failed revocation checks, namely that they fail gracefully. I’ve been aware of this issue in the past, but during my time away from PKI I had perhaps imagined that improvements had been made. Browsers generally do not apply strict rules because if they did many sites’ SSL certs would raise warnings which would, of course, be ignored by end users.

I do this myself: I run the Certificate Patrol add-on for Firefox but yet ignore many of it’s warnings because, in spurts, there are just too many (e.g. for a period of a week or more Citicard’s site resulted in a warning for every new page that was loaded). Strict checking isn’t an issue only because the user would see too many warnings. There are also scalability and performance issues for revocation responders and, in particular OCSP responders.

PKI is hard and these issues are not easy to solve. We did a fantastic job with PKI in Adobe Acrobat, but that was in a different context. In the Acrobat context validating a signature and certificate was done automatically, but it was also a more explicit action. For that action you could take the time to review the details of a revocation warning failure. In the web context you are constantly being hit by new sites and new certificates and users expect to be able to continue to surf the web without seeing or knowing what to do with security warnings.

Those of us working on Acrobat’s PKI engine would often scoff at the 108 root certificates originally embedded in Netscape and Internet Explorer. With a system only as strong as it’s weakest link, and 108 roots from many different vendors scattered across the globe, it was easy to imagine a few weak SSL certificates being issued. Perhaps it’s a testament to those in the industry that over the ensuing years there have in fact been so few compromises of this nature.

In Acrobat we did not embed 108 difficult-to-revoke root certificates because we could not provide oversight for these CAs and because their certificate issuance policies did not match our policies or key use. Instead we embedded just one Adobe root certificate from which we could cross certify high value CAs to issue document signing certificates.

This gave us the control to revoke roots, but this wasn’t a magic solution. It wouldn’t protect against an intermediate CA having a compromised RA account, and in practise we probably couldn’t revoke a compromised intermediate CA certificate because doing so would break too many signatures and workflows. We also had difficulties rationalizing support for high assurance, sign-in-blood, hardware-based document signing certificates (e.g. GPO signatures) with more accessible certificates that enable a user to sign on their desktop.

How do you convey to a user the difference between high and not-so-high assurance signatures? How do you express trust for a bank certificate that is guarded in hardware and at the same time support SSL certificates for developers? A few years back Microsoft and the other browser vendors introduced support for EVSSL certificates, which I believe was a good idea. Even though many users may not notice the presence or, more importantly, lack of presence of EVSSL security indicators in the browser chrome, they are a good step that can only be improved on as browsers get better with their security indicators.

Another suggestion is to allow users to group certain functions, such as access to financial sites, and indicate that these always require EVSSL certificates with no cross site or non SSL access, and then have these rules administered automatically. This too could be difficult to administer and explain, at least initially. It is all made more difficult by the fact that there are so many software stacks that use SSL. You might convince one browser to, for example, always check a certificate domain against the URL domain, but you won’t get them all to do this. An attacker will choose the soft targets first.

PKI security is difficult but good SSL PKI security doesn’t really matter if our DNS lookup system can be compromised, which it can. DNS compromises haven’t really been seen in the wild yet, but they’d allow MiTM attacks that not only compromise revocation checking, but the SSL connection itself for many software stacks.

Fortunately there are smart people working on solving the DNS problem with DNSSec. Security never seems to be glamorous, but is criticaly important, and my hat goes off to all those in the industry who’s work is often only appreciated when a high profile problem is avoided.

Update: Mozilla has posted their response to the Comodo breach.

Update: EFF’s Chris Palmer put together this slide presentation essentially recommending that end user’s maintain a white list of the sites and associated certificates that they trust. This amounts to a parallel trust system. I agree with this, though I’ll twist this a bit for my own product interest. My interest has been transactions with financial institutions and I’ve worked on a couple of products in this space during the past few years. In both situations the model has been for the products to be able to connect with multiple financial or other businesses and in both situations I’ve maintained my own trust white list of businesses and associated certificates. In neither case do I ask end users to make any security decisions whatsoever, beyond initial use of my product. You simply cannot ask end users to make such decisions.

Update:

05 APR 2011 - More analysis over at EFF shows that certificate authorities have issued more then 37,000 certificates to unqualified names. More reason for maintaining a parallel white list system.

06 FEB 2012 - Google to strip Chrome of SSL revocation checking and will instead push black lists with periodic updates.

Comments