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

[Simon Josefsson]

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.

/Simon