Security team successfully cracks SSL using 200 PS3's and MD5

Fri Jan 2 22:14:17 UTC 2009

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 at hopcount.ca] 
Sent: Friday, January 02, 2009 11:40 AM
To: Joe Greco
Cc: nanog at 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