deprecating MD5 in signature verification for gnutls-{cli, serv}

[Tomas Mraz]

On Mon, 2009-01-05 at 14:42 +0100, Simon Josefsson wrote:
> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
> 
> > Hi folks--
> >
> > In light of the recent demonstration of an attack against
> > X.509 PKI  using weaknesses in MD5 [0], i'm quite happy to
> > see that you must explicitly enable the use of MD5 for
> > certificate validation in gnutls for over 3 years
> > (from the 2005-11-07 NEWS entry):
> >
> > - Due to cryptographic advances, verifying untrusted X.509
> >   certificates signed with RSA-MD2 or RSA-MD5 will now fail with a
> >   GNUTLS_CERT_INSECURE_ALGORITHM verification output.  For
> >   applications that must remain interoperable, you can use the
> >   GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 or GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5
> >   flags when verifying certificates.  Naturally, this is not
> >   recommended default behaviour for applications.  To enable the
> >   broken algorithms, call gnutls_certificate_set_verify_flags with the
> >   proper flag, to change the verification mode used by
> >   gnutls_certificate_verify_peers2.
> 
> Hurray.  Some people were against that move at the time, but I think it
> was the right choice.
> 
> > However, gnutls-cli seems to blithely accept certificates that *are*
> > signed with an md5 hash.  You can see this from a debian system with:
> >
> > echo | gnutls-cli --print-cert --x509cafile /etc/ssl/certs/Equifax_Secure_Global_eBusiness_CA.pem support.mayfirst.org | certtool -i
> >
> > This seems to be the case with both 2.4.2-4 and 2.6.3-1, afaict, 
> > but i haven't tested with 2.7.x. 
> >
> > Are there plans to change this?
> 
> I suspect that is a consequence of the now sub-optimal chain validation
> algorithm the library is using that pre-empts some of the more advanced
> tests on chains of length 1.  The patch I proposed to really solve the
> GNUTLS-SA-2008-3 problem should fix the MD5 bug, but it had other
> consequences.  Maybe this is worth revisiting, and fixing the
> side-effects, we really should reject ALL chains with RSA-MD5 signatures
> in them.

If the only MD5 used in signatures is in the _trusted_ CA cert (and not
in the leaf and intermediate certificates) it is OK. But it is not the
case of the support.mayfirst.org site. But I don't see how the removal
of the last selfsigned certificate from the chain could break the
algorithm. There must be some different bug in play.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb