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

Brian Keefer chort at smtps.net
Sun Jan 4 21:02:06 UTC 2009


On Jan 4, 2009, at 12:05 PM, Joe Greco wrote:
>
> The opinions on whether or not it is necessary to replace certs  
> seems to
> vary depending on whose opinion you're listening to, but a  
> relatively safe
> rule of thumb for this sort of security issue is to take the path  
> that is
> most likely to avoid risk, which would seem to be replacing certs.   
> To the
> extent that VeriSign is already doing this, it would seem that there  
> is a
> certain level of agreement with that assessment.
>

I would attribute that much more to desire to avoid the risk of bad  
PR, rather than the risk that it's possible to clone existing certs.

"SSL is cracked, VeriSign to blame!" was pretty much the top security  
story for several days.  They had to do something to turn around the  
perception, despite accurate analysis and publications by  
organizations such as Microsoft.  Perception is reality, and  
regardless of the technical merits, a significant amount of people  
seemed to believe that any certificates that mentioned MD5 anywhere in  
them are at risk of some unknown, but really scary Badness(tm).

I agree with VeriSign that offering to reissue certs is the smartest  
business decision they can make, considering their tagline is "The  
Value of Trust".  I disagree that it was technically necessary.

Reissuing existing certificates signed by MD5 accomplishes nothing.   
Participation is voluntary, so if someone had managed to create a  
rogue CA, they certainly would not voluntarily destroy it by having  
their cert reissued!  Technically the only thing necessary to prevent  
this attack has already been done, and that is to stop issuing certs  
signed with MD5 so that no one else can create a rogue CA via this  
means.

If they truly believed that there was a risk anyone else had done this  
already, they would need to revoke the CA cert, i.e. every vendor who  
shipped their CA cert in the default trusted issuer bundle would need  
to remove or invalidate it with a software update, but that would  
break _all_ the valid certificates signed by the CA.  In order to do  
that, they would need to proactively contact every customer with a  
valid cert to make sure they were updated.  What percentage of their  
customers do you think they would be able to reach (haven't changed  
contact information, etc)?  How many application vendors would  
actually remove the old CA and add the new one in a timely manner?   
How many of those vendors' customers would actually upgrade to the new  
version?

So they've done what they need to in order to prevent future exploits,  
and obviously they aren't that worried that the exploit has actually  
been performed maliciously in the past.  Offering to reissue existing  
certs is a PR smokescreen (although a necessary one).

I think there's a huge fundamental misunderstanding.  It seems that  
the popular belief is that it's possible to use an existing MD5  
signature for any evil bits that you choose, which is not the case.   
The actual exploit in this case is the ability to "unlock" a normal  
certificate to make it a CA certificate.  Of course phrasing it that  
way wouldn't be quite so sensational (and wouldn't have accomplished  
the researcher's goal of raising awareness to the weakness of MD5), so  
now we have mass misperception, which has become reality since  
anything that is published is automatically true.

I'm not saying it's bad that people are shying aware from MD5, I just  
like to be accurate.

In any case, it has spawned some healthy discussions so I would say it  
was worthwhile.

--
bk
CA cert:  http://www.smtps.net/pub/smtps-dot-net-ca-2.pem

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1613 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20090104/0b13fbd4/attachment.bin>


More information about the NANOG mailing list