Bug#514807: Regression in libgnutls security update
emallcut at gleim.com
Wed Feb 11 21:54:13 UTC 2009
Simon Josefsson wrote:
> The CVE-2008-4989 problem was that parts of the chain validation
> algorithm was not executed properly. Rejecting V1 CA's is one of those
> parts, so I believe this is the intended consequence of the
> CVE-2008-4989 fix.
I understood the primary problem to be that if the last (root) cert was
self-signed then its signature of the next-to-last cert would not be
checked. The other checks on the last cert would also not occur but
these were relatively minor.
>> This change actually brings gnutls in line with its documentation,
>> however it is still a change in behavior that I think is unsuitable for
>> a stable security update.
This is my main emphasis. Whatever happens with lenny, changing this
behavior in etch breaks existing setups.
>> This also affects the same set of packages in lenny. I suppose the
>> "right" way to solve it in lenny would be to patch all the libgnutls
>> users which assume v1 CAs should be trusted. However I'm not sure of the
>> reaction to filing several possibly RC bugs at this point.
> This would leave users exposed to the security problems inherent with V1
> CAs, which seems like a bad thing. The proper fix is for users to move
> away from all V1 CAs.
What are the other significant problems with v1 CAs? Trusting a CA in a
list of certs which is provided with the understanding that they are to
be trusted doesn't seem a huge problem. (That being my interpretation of
the semantics of the configuration of nss_ldap etc.)
> What can be done here is to produce better documentation, perhaps in
> release notes. People must be aware that trusting X.509 certificate
> chains containing RSA-MD5 signatures or V1 CAs is insecure.
I don't disagree, but breaking working configurations, not all of which
are as insecure as you fear, doesn't seem like the best plan, especially
since there was no advance warning.
More information about the Pkg-gnutls-maint