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

[Tomas Mraz]

On Mon, 2009-01-05 at 19:48 +0100, Tomas Mraz wrote:
> 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.

And the bug is that ret is not set to 0 in _gnutls_verify_certificate2()
in case the unsecure algorithm in signature is detected. The same holds
for crl signature verification in _gnutls_verify_crl2().

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb