On 01/03/2009 11:59 PM, Nelson B Bolyard:
As I understand it, Eddy, the situation with CertStar was a bug which caused the code to simply fail to invoke the facilities that do the DV validation (or verification, or whatever the right term is for that).
If that were correct, just a walk-through without further testing would have revealed that. That's not even called debugging, that's a check one does to see if the program works at all.
Additionally, I'm not even blaming certstar for this, the failure is clearly that of Comodo. Would they have taken out one certificate from them, they would have found that something important is missing.
The input, which was the DNS name that should have been validated, wasn't checked. As I understand it based on messages I have read, the facilities existed to do the check, but a small bug kept them from being invoked, a small bug that was (reportedly) easily and quickly fixed.
Both assumptions are in my opinion incorrect, as for days later on somebody from Mozilla could still see the "renew" pages. I've made a screen shot of that one too.
In StartCom's case, likewise, an important input was not checked. It was the email address to be used, rather than the DNS name, that wasn't checked.
Not entirely correct, but similar.
But either way, the result was that a check was not performed, and consequently, a cert was issued for a domain name that was not properly under the control of the party to whom it was issued. Thus, these two events appear to me to be failings of a comparable magnitude.
Yes. But with all due respect the result of both events is quite different.
It's true that exploiting one of these required a little more work on the part of the "attacker" than the other. One required nothing more than that the attacker type in the DNS name he did not control, while the other required that the attacker alter the form to make it include an email address that had not been present as received from the CA/RA, but both are well within the scope of things that most serious attackers can readily do, as recent events have shown.
It required to proxy the all responses from and to the server. A simple form as you suggest wouldn't work.
Both of these "bugs" might have been, but were not, detected until a researcher/attacker found them and reported them.
Wrong! We (the system actually did) detected and took active actions within less then ten minutes. Theirs came after more then three hours and only after posting to this list. I think that there is a clear difference, both in the protection of preventing the higher value certificate which wasn't issued (same would have been true for many other high-profile sites including Mozilla) and in the overall response immediately thereafter.
I have no evidence that either failing was intentional. They were just bugs.
As I see it, our case indeed was a bug, the Comodo case was negligence.
One was perhaps less obvious than the other, but both had consequences that were of potentially of similar magnitude, IMO.
I think the constellation and policies are inherently different between Comodo and StartCom. It's not by chance that StartCom doesn't have a stipulation for RAs. Many other policy decisions and implementations are entirely different (intentional). May I quote Mike Zusman:
"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."
If you don't see the difference between both events I can't help you (and I'm not talking about the money stuff he mentioned).
-- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
