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

Tomas Mraz tmraz at
Mon Jan 5 19:48:45 CET 2009

On Mon, 2009-01-05 at 14:42 +0100, Simon Josefsson wrote:
> Daniel Kahn Gillmor <dkg at> 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
> >   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 | 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 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

More information about the Gnutls-devel mailing list