I agree with all three of these issues -- it's not *just* this reseller, it's potentially the entire reseller network, and it's entirely possible that the problem exists across multiples. (Especially if Comodo delegates full Registration Authority capability without verification, which seems to be the case -- though they could have simply issued a sub-CA certificate.)
It occurs to me that there is no facility in Firefox or other Mozilla products to provide an explanatory dialog that there's an issue, and such a facility would be extremely useful at this point. Being able to print a message to the user like "The Mozilla Foundation has identified issues with the trusted root that issued this certificate which prevent Firefox from being able to guarantee that this is truly the site to which you intended to go. While it is unlikely that this is a widespread problem, and an attack would rely on more technical intrusions into the network, the nature of these issues requires that you be warned of this circumstance so that you can exercise appropriate levels of caution. The Mozilla Foundation is working with the trusted root to resolve these issues." would help a lot. (I word it like that because in order for an attacker to succeed he would need to also hijack DNS, or place a entry in the user's hosts file.) Of course, this would be an NSS change (the addition of a 'trust suspended' bit, in addition to the trust flags), a Firefox/Thunderbird code change (to look for that bit), and a chrome change (to explain what's going on). Or even a check for the name in the hosts file to see if it's overridden from DNS. Placing an entry in a user's hosts file is easier than hijacking DNS, or at least it's supposed to be. I'm pretty sure we're all aware of the fairly recent cache poisoning attack, but the people who write BIND pushed out a change to protect against it very rapidly. The addition of a 'trust suspended' bit is primarily unlikely to happen, though, because there's too much inertia in the way things are to do what needs to be done to fix the authentication system to allow a root to stay in while the user is potentially at risk. -Kyle H On Mon, Dec 22, 2008 at 9:09 PM, Frank Hecker <hec...@mozillafoundation.org> wrote: > Kyle Hamilton wrote: >> >> I advocate at least temporarily removing the trust bits from Comodo >> until a new external audit can be completed, with an eye toward >> ensuring that Comodo, not the reseller, perform the domain >> validations. > > There are two general reasons for pulling a root, to address a clear and > present danger to Mozilla users, and to punish a CA and deter others. My > concern right now is with the former. I see at least three issues in > relation to that: > > 1. Issuance of further non-validated certs by this reseller. Comodo seems to > have addressed this by suspending the reseller's ability to get certs > issued. (I can testify that this is the case, as I tried to duplicate Eddy's > feat earlier today and got my uploaded CSR rejected.) > > 2. Potential problems with certs already sold through this reseller. Comodo > should investigate this and take action if needed. (This need not > necessarily require revoking all certificates associated with the reseller; > for example, the existing certs and their associated domains could be > re-validated, the registered domain owners could be notified of the > potential for bogus certs floating around, etc.) > > 3. Potential problems with other Comodo resellers. I'm not going to tell > Comodo how to operate its reseller network, but they certainly should take a > look at whether and where this might be a problem with other resellers, and > how they could revamp their systems to reduce potential problems with > resellers. > > Pulling a Comodo root will knock out Firefox, etc., access to thousands of > SSL sites, maybe tens of thousands. Given the disruption that would cause, > the final decision on this IMO should be made in conjunction with the > Firefox security folks. From my point of view I'd wait on more information > regarding items 2 and 3 above before making a recommendation. > > Frank > > -- > Frank Hecker > hec...@mozillafoundation.org > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
