Gervase Markham wrote: > - 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.
As far as I can see, there is no way around having at least an optional extension that allows to check for weak keys in a blacklist approach. The only place to migitate this problem is on the user side -- i.e. in the browser or it's crypto provider. All the other strategies leave significant attack surface. # Revocation: - As far as I know not all CAs support OCSP and a lot of older certificates provide no OCSP-URI. They will stay attackable without blacklist. But I have no statistics about that yet. - Revocation goes *really* slow: We checked the revocation statistics of Verisign: the second half of Mai they had even less revocations than in the second half of april or march. Until the 1st June we still found (in germany) about 3 percent of 4381 servers withe valid certificates using weak certifcates including a lot of online shops and even payment providers. This will not simply go away anytime soon -- especially if browsers don't complain. # detection of weak sites: Given that revocation does not work with current browsers every site that ever published a weak certificate can be spoofed. But having a site on the "list of shame" that revoked it's weak certificate soon after publication of the problem is not really fair. So this only works with functional online revocation checks -- but see above. # Expiry: there is a weak certificate for a big german bank out there. It is valid until 2011. And for sure it is not the only one. Having the blacklists downloaded after the installation makes sure that they don't increase the download of the browser or the security update. It also adresses an additional problem that has not been mentioned yet: the blacklists are going to grow significantly if you strive for completeness. The current lists only cover the common situation with 1024/2048 keys being generated on 32 Bit Intel systems. There will be other key lengths, additional keys on 64 bit systems, systems with other endianess and maybe even a couple more possible side effects influencing the key generation. So you want to have a prioritised list of blacklists: the common ones covering 90% + X for the masses and more exotic ones for the paranoid among us. And don't forget that blacklists might need to be updated. There is a chance that blacklists are not correct. BTW: If somebody is working on such an extension/patch/update, I would appreciate it, if he could notify me. We are thinking about having a blacklist check built. bye, ju -- Juergen Schmidt Chefredakteur heise Security www.heisec.de Heise Zeitschriften Verlag, Helstorferstr. 7, D-30625 Hannover Tel. +49 511 5352 300 FAX +49 511 5352 417 EMail [EMAIL PROTECTED] GPG-Key: 0x38EA4970, 5D7B 476D 84D5 94FF E7C5 67BE F895 0A18 38EA 4970 _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
