Nobody is perfect
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.
-Schmoilito
(cross post on Schmoilito’s Way)
5 comments Digg this5 Comments so far
Leave a reply
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 http://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 to a third party? Most likely not.
StartCom made the “Critical Event Report” publicly available here.
As you say, there are proper CAs doing their best to make the world a safer place, and there are those out for easy money.
Since there is no international system of approval for CAs, we are in a more difficult situation than when we want to know if a chartered accountant can be trusted. Each browser maker has to either do their own rather expensive vetting of CAs who want to be included in their rootstore, or they have to rely on somebody else’s rootstore. Those who go with their own rootstore risk negative attention if they are being more careful than the most lenient competitor – “browser X does not work with site Y” – because most users do not understand that it has something to do with security until after they have been burned.
Another problem is even bigger than the unreliable CA. The unreliable domain registrar has mostly been overlooked, even though they are in many cases easier to target.
Even if the certificate providers do their job, that does not help much if the registrar does not provide up to date and truthful information about who owns the domain. Nor does it further net safety that some will let a domain be transferred quickly and without an audit trail, do not check the identity of the new owner, or any number of other sloppy behaviours we know have caused problems in the past.
Wow, thanks for the timely blog. I found this via Google researching for the keyword “comodo sucks” just to check if there is something negative being said about the company.
We were about to consider purchasing code signing certificate from them. But with this issue, I think we better stick with the other guys: either Verisign or Godaddy
- Ismael
I work for secure128.com who is a wholesale reseller (registerd agent) of several SSL brands. We considered also reselling the Comodo SSL brand but decided against it because of this very issue.
As Bjorn posted above, “there are proper CAs doing their best to make the world a safer place, and there are those out for easy money.” is 100% correct in Comodo’s case.
The simple fact is that when you become a reseller of Comodo, you get the option in their portal to simply “checkmark” a box acknowledging that you have gathered all the required vetting documentation from your SSL customer for each order placed. This completely pushes off the responsibility of verifying domain owner’s identities from the Certificate Authority (Comodo) to the resellers who are NOT in the business of verifying identities.
In short, Comodo does not provide any form of domain owner identity verification through the resellers of their products at all! Sure they provide encryption but give you no idea of who actually owns the website you’re attempting to trust.
Pathetic!
-Dom Montgomery