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

Sun Jan 4 03:55:34 UTC 2009

On Sat, Jan 3, 2009 at 1:41 PM, Nick Hilliard <nick at foobar.org> wrote:
> Christopher Morrow wrote:
>> This is a function of an upgrade (firefox3.5 coming 'soon!') for
>> browsers, and for OS's as well, yes? So, given a future flag-day (18
>> months from today no more MD5, only SHA-232323 will be used!!)
>> browsers for the majority of the market could be upgraded. Certainly
>> there are non-browsers out there (eudora, openssl, wget,
>> curl..bittorrent-clients, embedded things) which either will lag more
>> or break all together.
>
> I think you might be downplaying the size of the problem here.  X.509 and

I wasn't, not intentionally.. I was trying to address the problem
which the researchers harped on, and which seems like the hot-button
for many folks: "oh my, someone can intercept https silently!!"

I understand there are LOTS of things out there using certs for all
manner of not-http things. I also understand that by telling a browser
class that they shouldn't accept anything but sha-X seems workable. I
suppose having the CA's kick out ONLY SHA-X is a bad plan, but ...
maybe letting cert requestors select the hash funciton (not md5) is
better? (or a step in the right direction at least)

> TLS/SSL isn't just used for browsers, but for a wide variety of places
> where there is a requirement for PKI based security.  So when you talk
> about a flag day for dealing with SHA-X (where X != 1), have you considered
> the logistical problems of upgrading all those embedded devices around the
> world?  The credit card terminals?  The tiny CPE vpn units?  The old

I had... yup.

> machine in the corner which handles corporate sign-on, where the vendor has
> now gone bust and no-one has the source code.  And the large web portal
> which had a whole bunch of local apache customisations based on apache
> 1.3.x and where the original developers left for greener pa$ture$, and
> no-one in-house really understands what they did any longer.  Etc, etc.
>
> It's different if you have a protocol which allows parameter negotiation to
> deal with issues like this, but not so good when you don't.

agreed, 100%. There are also lots of folks using certs internally for
all manner of oddball reasons... signed on their own CA (perhaps
chained to a 'real' CA, perhaps not). They'll have to be accomodated
as well, of course.

-chris