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

[Simon Josefsson]

Edward Allcutt <emallcut at gleim.com> writes:

> retitle 514807 X.509v1 CA certs no longer trusted implicitly
> thanks
>
> Simon Josefsson wrote:
>> Edward Allcutt <emallcut at gleim.com> writes:
>>> Simon Josefsson wrote:
>>>> I suspect the problem is that you have a RSA-MD5 signature somewhere in
>>>> the certificate chain.
>>> Nope, already checked that... gnutls-cli does work after all. It's the
>>> other modules linked to libgnutls that are failing.
>>
>> I believe the problem is that you have a V1 CA, which isn't permitted by
>> default by libgnutls.
> Only since this security update. I'm not saying that not trusting VA
> CAs shouldn't be the correct ideal behavior but it does seem very
> impractical right now. At the very least, can you postpone this change
> in functionality until lenny?

That's not my call to make, but haven't this fixed been rolled out for
etch already?  Anyway, I believe it is the right fix too: otherwise etch
users are left vulnerable.

>> 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.
> Those applications which need to change their flags should of course
> be patched to do so, but not in stable. This seems like a change in
> the API of libgnutls. A change towards what is documented, granted,
> but a change nonetheless and away from what most applications seem to
> expect.

The behaviour you have been seeing has always been the documented and
intended behaviour.  The _implementation_ had a security bug, which
caused these certificate chains to be accepted anyway.

I agree that whether this is a ABI change or not is a rather subtle
issue.  The patch does change what the user is seeing, so there is some
externally visible change.  Usually that means the ABI version has to be
incremented.  On the other hand, _any_ security patch is in the same
situation.  When you close a security hole, you change how users can
interact with the software.  However I don't think a security patch is a
valid reason to bump the ABI version.  Debian etc need to be able to fix
security problems without bumping the ABI version of a library and
re-linking every application.

>> For explanation of why V1 CA's are bad, see:
> I understand that. The argument against
> GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT is very strong, but the
> argument against GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT seems rather weak,
> especially given most applications give a list of trusted CAs, not
> non-CAs.

I think the argument applies equally strong to both flags.  What
difference do you see?

I think we should not second guess that "most applications" only put CAs
in the trusted cert list when it is allowed to put EE certs there too.
It seems better to close the security holes.

> In addition, at least one very popular CA still seems to use a v1 cert
> as their root. They have new v3 root certs however these aren't
> included in ca-certificates until lenny.

These users are at risk regardless of what GnuTLS does, so I believe
some effort needs to go into fixing that.

>> I'm tagging this as wontfix since this is the documented and intended
>> behaviour.  I am sorry you had to notice it through an upgrade --
>> however the reason for the upgrade was to close this hole.
> Hmm, I thought the reason for the upgrade was to close this hole:
> CVE-2008-4989. Fixing this deviation from documentation was just a
> side-effect.

The CVE-2008-4989 problem was that the implementation deviated from the
documentation and intended behaviour: certificate chains weren't
validated properly enough.

/Simon