Something worth noting. I am not sure about Firefox, but with IE 7 (and IE 6 when CRL validation is enabled) when a the browser encounters a revoked certificate, it does not present the usual "yes/no" box. Instead, one gets a message basically saying "certificate is revoked, you can't continue, period". Now, if the user is smart enough they can go into the advanced settings and turn off CRL validation and get around the error. Though not bullet-proof, that is better than just a "yes/no" box. In a perfect world, all certificate checks should result in a non-bypass-able error message. But the wide spread nature of self-signed certs and the lack of knowledge of many tech staff would make this a very hard position for any web browser vendor to swallow. In the near term, it would be nice to see browsers start to implement mandatory CRL checking for all non-self signed/root-level certificates. Ensuring that a each tier of the PKI has a time/signature valid CRL published (note, many root certificates do not publish CRL paths for themselves, hence the exception for them and self-signed). Speaking of this attack specifically. Publishing a CRL that would revoke this certificate would be basically useless. Since the CRL path that is used to valid a certificate is contained in the certificate, not the issuing CA's certificate. And a potential attacker would have little reason to point to a CRL that would incriminate themselves. (Note, there are a *few* applications that actually do mandate strict CRL checking, and thereby require the certificate to point to a valid CRL signed by the issuing CA, though they are not very common). My $0.02, Adam Stasiniewicz -----Original Message----- From: Joe Abley [mailto:jabley@hopcount.ca] Sent: Friday, January 02, 2009 11:40 AM To: Joe Greco Cc: nanog@nanog.org Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 On 2 Jan 2009, at 12:33, Joe Greco wrote:
We cannot continue to justify security failure on the basis that a significant percentage of the clients don't support it, or are broken in their support. That's an argument for fixing the clients.
At a more basic level, though, isn't failure guaranteed for these kind of clients (web browsers) so long as users are conditioned to click OK/ Continue for every SSL certificate failure that is reported to them? If I was attempting a large-scale man-in-the-middle attack, perhaps I'd be happier to do no work and intercept 5% of sessions (those who click OK on a certificate that is clearly bogus) than I would to do an enormous amount of work and intercept 100% (those who would see no warnings). And surely 5% is a massive under-estimate. Joe