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