Bug#514807: Regression in libgnutls security update

[Edward Allcutt]

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.

-- 
Edward Allcutt
Network Operations