[Please respect the Followup-To header, set to mozilla.dev.security] Many of you will know about the problem with weak keys generated on Debian or Debian-derivative systems between certain dates.[0] This affects SSL certificates generated on those systems. CAs trusted by Firefox have signed, and therefore endorsed, many such keys.
Once a hacker finds a server using a weak key, they can use the public key to find the private key and so MITM or spy on traffic to that server perfectly. All the relevant security indications will be present. This negates all security in the SSL model. Current data indicates that there may be up to 26,000 such keys out there being used on public websites.[1] We are attempting, through various channels, to get a firmer number and a list of vulnerable sites. It seems that CAs are not bothering to contact their customers with weak keys[1], although they are of course revoking the keys of customers who ask, and reissuing certificates.[2] Firefox 3 has caching OCSP turned on by default (with "soft-fail") and so would detect the revocation of these keys. 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. Here are some possible options (not mutually exclusive) for what to do: - Do nothing Once Firefox 3 is released, many people will upgrade. This means they will be using soft-fail OCSP, and so will detect attempts to use revoked keys. 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. This might be a reason to try and expedite pushing Firefox 3 into the Firefox 2 update channel. - Modify NSS to detect weak keys 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 If we can get a fairly complete list of vulnerable sites (which might be smaller than the hashes of a large number of keys) and their key fingerprints we could modify Firefox or NSS to refuse to connect to them until the key changed. - Add the sites to the malware or phishing feeds Quite a drastic option, but we could even leverage existing code by adding the vulnerable sites to the feeds of phishing or malware sites. - Contact CAs to put pressure on for them to contact their customers 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" If and when we get good data on the extent of the problem, we could try and shame CAs into doing something. "3% of FooCA-signed certificates are totally insecure. Is yours one of them?" - Attempt to contact site owners But 26,000 sites is a lot. We could try cross-referencing the sites with Alexa data to get a priority order. - 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. - Ship a Firefox 2 update with some built-in CRLs If OCSP is not an option, the next Firefox update could include static copies of the various different major CAs' revocation lists from the period concerned. These would probably be of significant size. - Something else Suggestions? Gerv [0] http://www.us.debian.org/security/2008/dsa-1571 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=435082#c22 [2] http://wiki.debian.org/SSLkeys#head-5450db0076b3d85650f72117a9884f89d2349032 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=435082 _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
