The day after the ComodoHacker pastebin post — which is, I think, the most informative piece of post-incident material we have on the Comodo affair from last week — and I am still trying to think clearly about what the certificate-authority infrastructure actually looks like now. The technical facts from the Comodo statement are reasonably clear. An Italian reseller of Comodo, GlobalTrust.it/InstantSSL.it, was compromised on 15 March. The attacker, with the reseller's authority credentials, requested nine certificates for high-value domains: three for login.yahoo.com, one each for mail.google.com and www.google.com, login.live.com, login.skype.com, addons.mozilla.org, and a "global trustee" certificate. Comodo issued them. The compromise was detected within hours; the certificates were revoked; Mozilla shipped MFSA 2011-11 on 22 March pulling the trust before public disclosure; Microsoft pushed KB2524375 the same day.
Then yesterday the ComodoHacker post appeared, claiming to be from a 21-year-old Iranian acting alone, with the private key for the addons.mozilla.org certificate as proof of ownership and a long, slightly hectoring statement of motivation that reads less like a state actor and more like an operator who has read too much of his own press already. Whether the lone-actor claim is true or whether this is cover for an Iranian state operation — Tehran's interest in mail.google.com sessions for in-country activists is obvious enough, particularly with Stuxnet still fresh and the Iranian state-actor framing already established — is the question that everyone is now arguing about, and I do not think it can be answered from outside.
What I can say is that the structural problem is independent of the answer. The Comodo trust chain at the moment includes an unknown number of resellers and registration authorities, each of which can request certificates that browsers will trust globally. There are several hundred root CAs in the Mozilla trust store; each has some number of intermediate authorities below it; the practical population of organisations capable of asking for and receiving a certificate that any browser will accept is in the low thousands. There is no published list. There has not, until last week, been a public incident that demonstrates the practical attack surface.
The defensive responses the operator community has been discussing for the past two years — DANE, certificate transparency, certificate pinning at the browser level, the work Moxie Marlinspike has been doing on Convergence — are, in light of this incident, no longer "interesting research direction" but operationally pressing. None of them are deployed at any meaningful scale. None of them are on a clear path to deployment. The browser vendors have the most leverage, but the standards work is in early stages and the deployment will take years. Meanwhile the trust model that protects every TLS-protected login form on the public internet against the kind of attack Tunisia demonstrated in January is, as of last week, demonstrably weaker than every CISO conversation has been assuming for a decade.
I have spent the morning auditing what the implications are for the engagements I run. The honest answer, for everything except the very highest-value internal services, is that there is nothing material a single client can do today beyond pushing harder on certificate-pinning where the infrastructure permits it (which for most web applications it does not), and being more sceptical of the chain-of-trust assumption that runs through every "we use HTTPS" tick-box on the controls statement. There is a longer conversation about operational monitoring of CT-style certificate logs that I will need to have with Browne Jacobson and Towry when something deployable exists. At the moment, it does not.
The narrower question is what to do about the nine certificates. They are revoked. The revocation list is in OCSP, in CRLs, and in the browser-vendor blocklists. But OCSP soft-fail is the default in most browsers, which means that a man-in-the-middle who can suppress the OCSP response will see the certificate accepted. Hard-fail OCSP would close that gap; it would also break revocation in the perfectly common case where the OCSP responder is briefly unreachable, which is why nobody runs hard-fail OCSP. The structural remedy here is OCSP stapling, which has been in the relevant RFC since the TLS extensions were standardised and is deployed on essentially nothing. There is a thread to pull on.
The final thing I want to note is the ComodoHacker rhetoric. The pastebin post contains the line "I'm a single hacker with experience of 1000 hackers", which is at least a memorable formulation, and a block of text claiming political motivation and personal grievance against the West that reads, to me, as cover. Real lone actors do not write political manifestos. State actors do not, in my experience, post the private key of a stolen certificate to pastebin to gloat. The most coherent reading is that we have a state operation laundered through a public lone-actor cover story, and that the operator who wrote the pastebin post is willing to wear the cover because the state has paid him enough to do so. I cannot prove this. I will be reading Bruce Schneier over the next fortnight to see if the analysis firms up.
The next post is probably the SQL-injection methodology piece I have been promising the engagements team since January, unless the certificate-authority story produces a second incident, which on present indications is more likely than not.