Recently, several people noticed that GnuTLS behavior did not match its documentation with respect to two significant security concerns, both regarding X.509 certificate validation:
- Certificates with MD5 digests were considered acceptable for validation. They should not be, because of known weaknesses in that digest algorithm.
- Version 1 X.509 certificates were being accepted as Certificate Authorities if placed in the list of trusted certificates. It is impossible to distinguish between a V1 Authority certificate and a V1 End Entity certificate. This makes placement of such a cert in the trusted certificates list dangerously ambiguous, because you don't want holders of an end entity certificate to be able to act as certificate authorities)
GnuTLS has been fixed upstream, and a fix to at least the latter problem has already propagated into etch via a security upload. The lenny packages should already behave as documented (no MD5 digests accepted in cert validation, v1 certificates not explicitly acceptable as authorities).
However, this means that if you use GnuTLS-linked tools to connect to systems whose certificate chains rely on either MD5 digests (in anything but the root certificate) or on v1 certificates for any of the certificate authorities, your connections may fail due to this stricter validation.
So what can you do to make sure that the infrastructure you rely on or maintain does not depend on these outmoded and insecure features of X.509? Read on for concrete steps for administrators, developers/maintainers, and end users...
This entry has been truncated read the full entry.