Hi Gerv, [Off-topic] For one I must notice the incredible inconvenience in working with Bugzilla and this mailing list. It happens many times that the same issue is discussed and tracked at different bugs in parallel. I'm a CC bug 434128 and just got aware of bug 435082. Can you tell me the best way how to KNOW about such bugs which are related and might interest me? I can't spend my time searching all day long and on a daily basis for new bugs. I guess there is a formula or something...?
[On-topic] Here is how I evaluate the situation. Debian users are generally more aware and more informed about problems such as these in relation to other server products (which includes obviously all brands). This situation doesn't apply always on shared hosting. StartCom offers two ways of creating server certificates, one way is to create ones own private key and submit a CSR, at the other way the Certificates Wizard creates it on behalf of the client. The majority of CSR submissions are for IIS servers with a small minority being for Apache users. The rest creates the keys at StartCom. Those keys aren't subject of this or similar bugs. Out of the Apache users which create their own CSR (and hence private key), Debian users are again a minority, at the most 10%. Judging from the revocation requests we received, at least one third of those requested revocations. There is about one third which didn't succeeded in installing the certificate or for other reasons haven't made use of the certificate (for example realizing the need for a dedicated IP address etc). Therefore we have about another one third which might be still using a weak key. This boils down for very few still affected sites, probably less then 1.66 %. Since all certificates issued at StartCom are valid for one year only, the risk assessment didn't warrant for a full scan of all public keys considering the effort which must put into such an effort. I expect the situation to be similar at most CAs. See also inline comments. Gervase Markham: > Firefox 2 does not have OCSP turned on by default. Both > browsers support CRLs, but do not have the capability to download CRLs > from URLs listed in certificates. > This is a known shortcoming of FF2 and inherits higher risks then weak keys. That's because if a certificate is revoked because of a weak key it was most likely requested by the subscriber himself and he wouldn't continue use of the weak key anyway. Hence this would make only sense if CAs would revoke such certificate unilaterally. > However, because CAs are not actively contacting their customers, many > weak keys will still be being used, and we'd have no way to tell if > there was an MITM going on in that case. > That's correct. > Lists of all the weak keys exist - we could create a database of the > first 8 bytes or so of the hash of each and get NSS to check it when it > sees a key. This would involve a code change to NSS and a security > update. We'd probably want to download the list of weak keys rather than > ship it with the update. NSS would then return an error to the > application if a weak key was found, and the connection would abort.[3] > > - Modify NSS/Firefox to detect weak sites > I would cite privacy concerns with such a scenario. > If we can get a fairly complete list of vulnerable sites > How do you intend to find them? > We could use our contacts with CAs to try and convince them to change > their position on customer contact. > > - Publish a "CA hall of shame" > And what if a CA refuses to comment or provide this information? > - Turn on OCSP in the next Firefox 2 security release > > This might help in the short term, with the same limitations as listed > under "Do Nothing" for the Firefox 3 update. But Firefox 2's OCSP > support is not as complete; it doesn't do caching, and it hard-fails. So > we might melt the OCSP servers, and that would severely degrade the user > experience because no-one could make SSL connections. > Yes, that's not a good option really. > - Ship a Firefox 2 update with some built-in CRLs > Again, see above that this makes only sense if an affected site owner would refuse to replace the certificate because of somebody detected a weak key. I haven't encountered such a situation yet and doesn't make much sense. > Suggestions? > > Even if it doesn't sound so good, do nothing is the right thing to do I think. Regards Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> Jabber: [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]> Blog: Join the Revolution! <http://blog.startcom.org> Phone: +1.213.341.0390 _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
