Dismay
December 24th, 2008
The Comodo fiasco is pretty depressing. We have a CA Policy that states we’ll might do something in situations like this, but Mozilla’s hands are pretty tied unless all browser vendors agree to remove Comodo. This inability to act is also the reality with EV certs, there’s just more flare in the UI.
Having to depend on coordinated action by competitors and certificate authorities is not a good situation to be in. Maybe we’ll learn some day.
December 24th, 2008 at 6:45 pm
Why are hands tied? Can’t Mozilla just “do the right thing” and cut the relevant root CAs from the next browser version? What other browsers do is up to them.
December 25th, 2008 at 3:27 am
I think that needing to depend on coordinated action is better than having one all-powerful dictator who is trusted to make all decisions.
(And I agree with Andy, why do you need to wait for others? If they don’t meet the CA policy then dump them.)
December 25th, 2008 at 11:43 am
I’m afraid that attitude is new and unfortunate. Firefox gained substantial market share because of the extra, sometimes inconvenient steps it took to ensure security. Just because some people would still be vulnerable isn’t a reason not to act.
As it happens this case seems to be being resolved pretty rapidly by Comodo and the reseller in particular question seems to have issues a limitied number of certificates which are being reviewed.
It seems clear that a better set of possible and rapid responses is required. I would include a mechanism allowing mozilla to rapidly modify the trust levels of Root CAs without shipping a new build… i.e. allow remote flipping of a switch within 24 hours, not the 1-week build-test-ship cycle which seems is curently required. I’d also include UI to explain that “The certificate being used has been issued by an authority which is no longer trusted by mozilla [Add exception]“.
In terms of the EV certs, I’d like to see a mechanism where mozilla.org could rapidly remove the EV level of trust from given providers, allowing the standard blue UI to be shown if it’s simply the case that some of the EV rules have been broken.
I hope there’s a proper design review of the process and the code to ensure that features like this are considered for the next practical release of Firefox.
December 25th, 2008 at 5:40 pm
the idea is that if we suddenly mark 100, or 1000 sites as having apparently “unknown” trust, people will assume our cert list is incomplete and switch to a competing browser which hasn’t blacklisted that set of sites.
as far as we, and our competitors know, most of the certificates issued by this CA are valid. And the CA has revoked the two known bad certificates.
Sadly most browsers “soft fail” if a CRL is unavailable – which means a local attacker can sink the CRL (or a remote attacker could DDoS the CRL).
It’s kind of like playing Poker with a really bad hand against 10 other players and not understanding the rules, but suspecting that no one has a good hand and that some people might be more willing to raise (stick around) than you are. – I can’t remember which specific bluff this most closely matches.
There’s also a risk that users will choose not to update if someone announces that our update will break one of their favorite servers. Or worse, if some press makes a more generic claim that the update will break some unspecified but “large” number of servers.
If people turn off updates, we lose.
December 26th, 2008 at 1:48 am
That’s a good reason to not link trust revocations to version numbers certainly, but that’s all. Firefox already does lots of checking in the background by default for phishing… why wouldn’t a ‘by default hard fail’ against a mozilla.org CRL (type thing) be a possibility. Would it be easier if a third party (e.g. Google) kept the list like the phishing check?
Frankly “the idea is that if we suddenly mark 100, or 1000 sites as having apparently “unknown” trust, people will assume our cert list is incomplete and switch to a competing browser which hasn’t blacklisted that set of sites.” shouldn’t matter. Either user security is more important that market share or it’s not. I really hope the priority is security.
I agree that in this case it appears that it’s a managable situation, but I’m more worried about the future where the CA is less responsive/malicious.
December 27th, 2008 at 12:13 am
David, I agree that user security is important. Is user security enhanced by them switching from Firefox to IE? If staying with Firefox, after controlling for the handling of this situation, is a security win for users, then it makes sense, to improve user security, to try to keep them with Firefox…
I’m pretty sure if the CA didn’t respond as well as this one did, the relevant CA root would in fact get removed, for what it’s worth.
December 27th, 2008 at 8:45 am
The response to this particular situation was really poor, and it gives no confidence that in a worse situation there would be a quick decision made to pull the root CA, or that that decision could be implemented quickly. I really hope this does serve as a wake-up-call and that steps are taken to:
Increase the number of options available in these situations
Clarify the policies to allow faster decision making
Allow faster implementations of those decisions
As for whether it’s better overall to secure your userbase and loose some users or keep them because you’re confident you’re more secure in other areas… there’s no clear answer. The first time you use the arguement it may be strong. Each use weakens it, however.
I’ll end with some numbers which on the surface may be persuasive but which are clearly only part of a much more complex puzzle.
Assume 20% Firefox users, 80% other.
Assume a vulnerability in all browsers.
No fix in any browser:
100% of web users vulnerable.
Fix in Firefox.
10% Firefox users switch to another browser which contains the vulnerability.
82% of web users vulnerable.
December 29th, 2008 at 8:53 am
Quote from Melih
CEO of Comodo
“One of our resellers had an issue in their system. We take this very seriously . We acted quickly and revoked the cert, we have suspended the reseller account, we are re-doubling our auditing and re-evaluating our procedures. We are not the first to suffer in the hands of DV certs ( DV certs are not for ecommerce)(there simply is no standard for these kind of certs) and we won’t be the last until a standard setup for DV certs. As it happens Comodo put forward a new proposal for a minimum standard for DV certs on 2nd of Dec 2008 (just few weeks ago) to the cabforum (the org that I initiated in 2005). As you all know, CABForum created the EV SSL standard for high assurance SSL certs called EV SSL (which creates a ceiling for high assurance validation) but there is no standard for where the floor should be for lower assurance certs like DV certs.
We hope this latest event will act as a catalyst to unite the industry and come up with a minimum standards for DV certs. DV certs have no place in the world of Ecommerce. Minimum standard for DV certs is well overdue! We owe it to our users!
Melih”
December 29th, 2008 at 8:54 am
http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html