Simon Josefsson wrote:
Edward Allcutt <emall...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
