Dan Kaminsky wrote: > > > Eric Rescorla wrote: >> At Fri, 8 Aug 2008 17:31:15 +0100, >> Dave Korn wrote: >> >>> Eric Rescorla wrote on 08 August 2008 16:06: >>> >>> >>>> At Fri, 8 Aug 2008 11:50:59 +0100, >>>> Ben Laurie wrote: >>>> >>>>> However, since the CRLs will almost certainly not be checked, this >>>>> means the site will still be vulnerable to attack for the lifetime of >>>>> the certificate (and perhaps beyond, depending on user >>>>> behaviour). Note that shutting down the site DOES NOT prevent the attack. >>>>> >>>>> Therefore mitigation falls to other parties. >>>>> >>>>> 1. Browsers must check CRLs by default. >>>>> >>>> Isn't this a good argument for blacklisting the keys on the client >>>> side? >>>> >>> Isn't that exactly what "Browsers must check CRLs" means in this context >>> anyway? What alternative client-side blacklisting mechanism do you suggest? >>> >> >> It's easy to compute all the public keys that will be generated >> by the broken PRNG. The clients could embed that list and refuse >> to accept any certificate containing one of them. So, this >> is distinct from CRLs in that it doesn't require knowing >> which servers have which cert... > Funnily enough I was just working on this -- and found that we'd end up > adding a couple megabytes to every browser. At least for the weak keys kudos to Debian's OpenSSL maintainer there exists an extension to Firefox which checks the keys, see <http://codefromthe70s.org/sslblacklist.asp>, as well as c't's SSLguardian for the Windows Crypto API, see <http://www.heise-online.co.uk/security/features/111039/0> and <http://www.heise-online.co.uk/security/features/111039/1> Stefan
