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

[Edward Allcutt]

Simon Josefsson wrote:
> Edward Allcutt <emallcut at gleim.com> writes:
> 
>> retitle 514807 X.509v1 CA certs no longer trusted implicitly
>> thanks
This didn't appear to work for me. Would someone mind pointing out my 
mistake?

>> Simon Josefsson wrote:
>>> 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.
It has been release for etch, that's the main cause of my problems right 
now.

>>> 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.
And several applications depended on this bug. If there are other 
applications which are actually more secure because of the change should 
we instead release security updates for the apps which were depending on 
  the bug? That seems acceptable to me. What does the security team 
think of this approach?

> 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.
I believe the ideal goal is that security patches don't have side 
effects that alter behavior unexpectedly (and hence no ABI/API change 
etc.). That constraint doesn't seem to have been met in this case, which 
is why I'm asking either for the patch to be modified (which seems 
simpler) or additional patches for all the affected apps.

I'm willing to try and produce patches for nss_ldap, pam_ldap and 
possibly apache but not to go hunting for other apps that might be affected.

>>> 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?
In the applications I'm concerned with, the trusted list is explicitly 
used only for CA certs. Arguably they should be using 
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT.

-- 
Edward Allcutt
Network Operations