Bug#514807: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"

[Simon Josefsson]

Edward Allcutt <emallcut at gleim.com> writes:

> Simon Josefsson wrote:
>> Simon Josefsson <simon at josefsson.org> writes:
>>
>>> The reason gnutls-cli doesn't complain is because it contains this code:
>>>
>>>   /* there are some CAs that have a v1 certificate *%&@#*%&
>>>    */
>>>   gnutls_certificate_set_verify_flags (xcred,
>>> 				       GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);
>>>
>>> I don't recommend doing the same in other applications, and we should
>>> probably remove it from gnutls-cli too.  It may be useful to create a
>>> parameter in other tools to enable the flag on a per-case basis, though.
>>
>> FWIW, I've worked on this in the gnutls 2.7.x branch.  gnutls-cli no
>> longer accepts V1 CAs by default, and there is a new --priority token
>> %VERIFY_ALLOW_X509_V1_CA_CRT to enable it for those that needs it.  The
>> priority string approach is what we recommend applications expose to
>> their users for configuring GnuTLS internal details.
> That's all very well, but it's a rather big change in functionality
> for stable. I doubt it would be acceptable to patch all the relevant
> apps which assume that their list of trusted CAs will actually be used
> as such.

Right, and I don't think these applications should be patched for two
reasons:

 1) That would open up for security problems.

 2) The GnuTLS documentation and API has a flag to enable V1 CAs to be
    valid as a CA root, and another flag to enable V1 CAs to be valid as
    an intermediate CA cert.  This implies the default is that the certs
    are intended to be disallowed.

> I can see the same change has been made in libgnutls26 in
> lenny. Should I file several RC bugs against the various modules
> affected? Bear in mind that their documented semantics are "a list of
> trusted CAs" so I think GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT would be
> entirely appropriate in those cases.

The documentation should be updated for these applications, to clarify
that V1 CAs are not permitted by default.  Alternatively, the
application documentation could just refer to the GnuTLS manual for more
technical discussions like this.

To patch the applications to use the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
would expose users to security problems, so I don't think that is a good
idea.

> Are there any apps which provide a list of trusted certs which should
> not all be considered trusted CAs? If not then perhaps
> GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT should be the default.

Good question, I think this should be discussed with application
authors.  My hope is that we can convince them that V1 certificates
should not be trusted by default even if the user provided such a
certificate in their trust list, due to the security problem with V1
certs.

(Another hope is that application writers extend their code to call the
GnuTLS gnutls_priority_* functions, then users can supply a GnuTLS
priority string to the application to set the flag that will make it
possible to use a V1 CA again.  This provides a way to work-around the
problem. It also makes it possible for GnuTLS to introduce new flags to
work around future similar problems, without a need to patch
applications.)

/Simon