Re: On the topic of SSL and MD5 (was Re: [NSE])

[Daniel Roethlisberger <daniel () roe ch>]

Brandon Enright <bmenrigh () ucsd edu> 2009-01-12:
> On Mon, 12 Jan 2009 10:46:39 -0800 bensonk () acm wwu edu wrote:
> > There's also a link to another blog post which describes
> > exactly how[4] MD5 sigs can be made safe.
>
> Comments like this scare the hell out of cryptographers.  The
> x509 singing certificate serial number is not meant to be a
> security field.  Making it a security field moves the problem
> away from strong crypto (RSA + hash) and into a serial number
> guessing game.

While I agree with most of your conclusions, your use of the
specific crypto terms below is incorrect:

> Right now MD5 is only vulnerable to second preimage attacks
> which can be dramatically improved using birthday attack
> techniques.  The second preimage attack has been improved quite
> a lot -- now it even works under chosen prefixes.

MD5 is *not* vulnerable to ``second preimage attack with chosen
prefixes'' right now.  The second preimage attack here would be
to generate a second certificate's to-be-signed part, which
matches the MD5 hash of a previously given certificate's
to-be-signed part.  If second preimage attacks were feasible,
then you could directly attack any root CA certificate signed
with MD5.  Alas, that isn't the case.  Yet.

What you actually meant are ``chosen-prefix collisions''.  In a
collision attack, the attacker will always generate two
to-be-signed parts with identical hash value (but not a
predetermined hash value).  Very important difference.

> A band-aid like choosing a better serial number is not a good
> "solution".  It is entirely possible that first preimage
> attacks will be developed on MD5 which will totally bypass
> /any/ field monkey business anyone tries.

The ``first preimage'' attack is normally termed just
``preimage'' attack.  It means to compute the original data which
was hashed (the so-called preimage), given a hash value.  Since
the original data which was hashed is public in the case of
digital signatures, preimage attacks are moot in this context.

> Even another good second preimage improvement could bypass any
> serial number.

Second preimage attacks would make all the serial number
guesswork obsolete, since you could just directly attack any
certificate.

> SHA1 is available today and works in all SSL capable
> applications.  Everyone should switch to SHA1.
>
> Also, consider this.  It doesn't matter if *your* SSL certs
> don't use MD5 -- someone can generate a new cert matching your
> details and sign it with /some other/ CA that *does* use MD5.
> Sure, your cert will go from being signed with CA XYZ using
> SHA1 to being signed by CA IJK using MD5.  Nobody will notice.
> If you are a user being MitM attacked, you have no way to get
> at the "real" CERT to notice that it is supposed to be signed
> with SHA1, not MD5.
>
> The best solution is to remove all CA certs that sign with MD5
> from your browser trust.  It is naive to think in a MitM
> scenario your Nmap scanner is going to scan and detect a cert
> signed using MD5 *before* the attack starts.

However, also consider that we need to phase out most/all
legitimate MD5-signed certificates before we can configure our
browsers to not trust a certificate if the chain includes
MD5-signed intermediate certs or it is itself MD5-signed.

-- 
Daniel Roethlisberger
http://daniel.roe.ch/

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org