Bug#514807: Regression in libgnutls security update
emallcut at gleim.com
Wed Feb 18 00:50:01 UTC 2009
Simon Josefsson wrote:
> Florian Weimer <fw at deneb.enyo.de> writes:
>> There doesn't seem to be industry consensus that X.509v1 root
>> certificates are a bad idea. This means that users have little
>> leverage against CAs and server operators when confronted with
>> problematic certificates.
> Doesn't the same hold for RSA-MD5 signatures? I'm not sure industry
> consensus is a good measure here. What we are relying on here is this
> part of RFC 5280:
Considering that gnutls is aiming to interoperate with software and
certificates produced by this "industry" (including OpenSSL and yaSSL)
I'd say consensus is of the utmost importance. Despite what we may wish
about conformance with published standards, the de facto standards don't
exclude v1 certs or RSA-MD5, although the latter is certainly on the way
> (k) If certificate i is a version 3 certificate, verify that the
> basicConstraints extension is present and that cA is set to
> TRUE. (If certificate i is a version 1 or version 2
> certificate, then the application MUST either verify that
> certificate i is a CA certificate through out-of-band means
> or reject the certificate. Conforming implementations may
> choose to reject all version 1 and version 2 intermediate
> GnuTLS doesn't have any API to provide this out-of-band information, so
> we simply reject version 1 certificates (unless a flag is set).
That seems like a good enough API to me. If the application is providing
a list of CA certs then it should set the flag. That is, however
unintentionally, an API change that shouldn't get pushed out silently as
a stable security update.
> Hm. It is interesting that it says 'intermediate certificates' in the
> last sentence. I think this is mistaken, the part of the algorithm
> applies to root certificates as well as end-entity certificates too.
I think it is not mistaken. To me it looks precise: Intermediate
certificates MAY be rejected but out-of-band-verified root certificates
MAY NOT be.
I've tested the previously posted patch which adds
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT to verify_flags. This restores the
previous behavior of trusting v1 certs on the trusted list. I tested for
the versions in etch (1.4.4-3+etch3) and lenny (2.6.4-1). Both nss_ldap
and apache mod_ldap began working again with the patched libgnutls
Is there anything else I can do to get this regression fixed at least in
etch? I'd rather not maintain my own patched version of gnutls.
More information about the Pkg-gnutls-maint