Just before Christmas, an admin from StartCom certificate authority disclosed that he was able to procure an SSL certificate for Mozilla.com from a registered agent of the CA Comodo. He was not authorized to obtain this certificate, and the RA and CA clearly failed to properly vette his cert signing request. Shame on Comodo. You can read the entire saga on mozilla.dev.tech.crypto.
The discussion resulting from StartComs blog post is quite interesting, and touches on many issues spanning from internal CA domain validation procedures, to how to revoke a certificate in the Mozilla root cert program. One issue in particular, is exactly what I talked about in my last post.
Frank Hecker, of the Mozilla Foundation, said "[right] now we have no real idea as to the extent of the problem (e.g., how many certs might have been issued without proper validation, how many of those were issued to malicious actors, etc.)."
When a flaw in a CA validation mechanism is uncovered, it can sometimes be trivial to fix. The hard part is determining if any other certificates were obtained by taking advantage of the same flaw, and then revoke them. Although I can imagine a methodology for this process, I can't comment on how any given CA would actually tackle this problem. Based on my own application security experience, I will say that I'm sure lots of logs that would need to be parsed, might not actually exist.
One person who commented on the StartCom post that started this all critiqued the post by saying it seemed dodgy that StartCom was blatantly pointing out flaws in a competing CA. The reader did, however, understand the severity of the problem that was found and thanked StartCom for publicly disclosing it. I agree with the reader, and I think StartCom did a good thing in disclosing this bug.
So in the interest of full-disclosure, here is what happened on Friday December 19 (three days before the StartCom disclosure). I found a flaw in StartCom's domain validation mechanism that easily allowed anyone to authorize themselves for ANY domain name, on various .TLDs. While I only tested .COM, many other TLDs were available including .GOV.
The screen shot above shows the domain names my StartCom account was allowed to create signed certificates for. These certificates would have been trusted by Firefox, but not Internet Explorer. The first one is a domain I control. Phishme.com and Intrepidusgroup.com are domains owned by my employer for which I am not an authorized contact, and for which I should not have been, but was, granted a signed certificate. Needless to say Paypal.com and Verisign.com are companies I'm also not authorized for.
Fortunately for Verisign and PayPal, a defense in-depth strategy succeeded for StartCom. While I by-passed StartComs domain validation process, my attempts to create a signed certificate for Verisign.com was flagged by a black-list and not permitted. This is good news for the prominent sites on the black-list, but bad news for lesser known sites that rely on the trust gained by having a valid SSL certificate (small credit unions, for example).
Because they're a good CA, the StartCom team was immediately aware of my attempt to get a certificate for Verisign. I disclosed the details of the flaw to them, and the simple problem was fixed within hours. But the question remains: did anyone else take advantage of the flaw?
PKI is not a perfect system, and there is no perfect CA. But, there are at least two types of CAs. One type treats SSL certificates as a cash cow, pushing signed certificates out the door, and counting the money. The second type is like StartCom. This second type understands that trust comes before money and that trusted CAs are a critical piece of Internet infrastructure.
(cross post on PhishMe)
Thursday, January 1, 2009
Nobody is perfect
Subscribe to:
Post Comments (Atom)
5 comments:
Yes that's correct. Mike Zusman detected a real flaw in our system by using an SSL proxy tool to change the values of the validation emails. The attempt to get a certificate for www.verisign.com was detected within 8 minutes and Mike was blocked from our systems. After a short conversation, it was reproduced and correctly fixed.
Nevertheless, this is under our direct control and needless to say that our further layers of defenses succeeded to prevent an attack on a high-profile target such as Verisign. A such, you are right, no system is perfect and mistakes do happen. However exactly because of that, special care must be taken and the system itself must be protected. More than that, retaining all evidences are important as well. As such we also had the capability to verify if other such attempts happened. We've found none.
There is a huge difference in my opinion between this flaw and that of Comodo, as no validation system was in place at all. That's not a flaw, it was simply non-existent. Would StartCom outsource domain validation or a third party? Most likely not.
StartCom made the "Critical Event Report" publicly available here.
People may remember that quite some years back, Verisign handed out certs for Microsoft to an unauthorized individual. It happens. In fact, according to The Byzantine General's Problem, it must occasionally happen when you have N parties involved and you cannot guarantee (N/2)+1 of them can be trusted.
In most real-world scenarios, it simply isn't cost-effective to meet that kind of guarantee, assuming you even can. Even the highest tiers of certification out there don't meet the mathematical minimum requirement and those are considered the realistic best for mission-critical stuff.
Even if you could meet such a standard, it might not help. MD5 and SHA1 are no longer considered cryptographically safe and there are question-marks over how well SSL 3.0 validates things anyway. The moment someone can reliably spoof a certificate, all the validation in the world won't help.
That doesn't mean it's all doom-and-gloom. The system does work, it mostly works very well, and kudos to all who have made it that way and will doubtless improve it in future. You're more likely to read about carelessness with unencrypted data on backup tapes, laptops or unsecured servers and those issues can certainly be fixed.
Given that banning stupidity isn't an option (a great pity), I await with interest to see what methods end up actually being used to improve security as a whole.
It's also interesting that Eddy Nigg (StartCom's founder) has thus far refused to give up the mozilla.com certificate despite a request from Mozilla to do so.
Seems the race to the bottom is over - the CAs are just as bad as each other.
My only connection with StartCom is as a customer. (Unfortunately Blogger doesn't want to work with my StartSSL OpenID at the moment).
The CertStar / Comodo certificate for mozilla.com that Eddy Nigg was able to obtain due to a lack of Domain Validation is all but neutralised now.
Comodo revoked the certificate, so anyone who configures their browser to check for revocation would not recognise the certificate as valid. Unfortunately, revocation checking is not turned on by default, not least because of the fear of causing users problem if the OCSP server isn't working properly. A recurring problem in Internet security is balancing user convenience versus security, though I believe revocation checking should be turned on with users being warned if the revocation check fails. In Firefox 3, choose Options, Advanced, Encryption Tab and press the Validation button.
Whilst talking about revocation checking, it would help if all CAs included the Authority Information Access extension for OCSP in their certificates. Some (admittedly lower value) certificates don't have this extension, such as Thawte Freemail client certificates, though it's arguably more important for server certificates.
Eddy has taken down the public server using this certificate, further neutralising it.
Hopefully we can reach a point where the situation is completely worked through and the private key is destroyed - but I would contend that Eddy can do much more serious damage to the PKI should he choose to as he has access to StartCom's root certificate.
More importantly, this and other recent PKI / certificate related news (such as the MD5 collision attack on RapidSSL will hopefully encourage wider use of OCSP.
Post a Comment