Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
Edward Allcutt emall...@gleim.com writes: retitle 514807 X.509v1 CA certs no longer trusted implicitly thanks Simon Josefsson wrote: Edward Allcutt emall...@gleim.com writes: Simon Josefsson wrote: I suspect the problem is that you have a RSA-MD5 signature somewhere in the certificate chain. Nope, already checked that... gnutls-cli does work after all. It's the other modules linked to libgnutls that are failing. 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. 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. 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. 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? I think we should not second guess that most applications only put CAs in the trusted cert list when it is allowed to put EE certs there too. It seems better to close the security holes. In addition, at least one very popular CA still seems to use a v1 cert as their root. They have new v3 root certs however these aren't included in ca-certificates until lenny. These users are at risk regardless of what GnuTLS does, so I believe some effort needs to go into fixing that. I'm tagging this as wontfix since this is the documented and intended behaviour. I am sorry you had to notice it through an upgrade -- however the reason for the upgrade was to close this hole. Hmm, I thought the reason for the upgrade was to close this hole: CVE-2008-4989. Fixing this deviation from documentation was just a side-effect. The CVE-2008-4989 problem was that the implementation deviated from the documentation and intended behaviour: certificate chains weren't validated properly enough. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
Edward Allcutt emall...@gleim.com writes: Simon Josefsson wrote: Simon Josefsson si...@josefsson.org writes: The reason gnutls-cli doesn't complain is because it contains this code: /* there are some CAs that have a v1 certificate *%@#*% */ gnutls_certificate_set_verify_flags (xcred, GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT); 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. FWIW, I've worked on this in the gnutls 2.7.x branch. gnutls-cli no longer accepts V1 CAs by default, and there is a new --priority token %VERIFY_ALLOW_X509_V1_CA_CRT to enable it for those that needs it. The priority string approach is what we recommend applications expose to their users for configuring GnuTLS internal details. That's all very well, but it's a rather big change in functionality for stable. I doubt it would be acceptable to patch all the relevant apps which assume that their list of trusted CAs will actually be used as such. Right, and I don't think these applications should be patched for two reasons: 1) That would open up for security problems. 2) The GnuTLS documentation and API has a flag to enable V1 CAs to be valid as a CA root, and another flag to enable V1 CAs to be valid as an intermediate CA cert. This implies the default is that the certs are intended to be disallowed. I can see the same change has been made in libgnutls26 in lenny. Should I file several RC bugs against the various modules affected? Bear in mind that their documented semantics are a list of trusted CAs so I think GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT would be entirely appropriate in those cases. The documentation should be updated for these applications, to clarify that V1 CAs are not permitted by default. Alternatively, the application documentation could just refer to the GnuTLS manual for more technical discussions like this. To patch the applications to use the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT would expose users to security problems, so I don't think that is a good idea. Are there any apps which provide a list of trusted certs which should not all be considered trusted CAs? If not then perhaps GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT should be the default. Good question, I think this should be discussed with application authors. My hope is that we can convince them that V1 certificates should not be trusted by default even if the user provided such a certificate in their trust list, due to the security problem with V1 certs. (Another hope is that application writers extend their code to call the GnuTLS gnutls_priority_* functions, then users can supply a GnuTLS priority string to the application to set the flag that will make it possible to use a V1 CA again. This provides a way to work-around the problem. It also makes it possible for GnuTLS to introduce new flags to work around future similar problems, without a need to patch applications.) /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
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
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
Simon Josefsson wrote: Edward Allcutt emall...@gleim.com writes: That's all very well, but it's a rather big change in functionality for stable. I doubt it would be acceptable to patch all the relevant apps which assume that their list of trusted CAs will actually be used as such. Right, and I don't think these applications should be patched for two reasons: 1) That would open up for security problems. Are there any problems other than trusting the V1 certs as CAs? Because that's what the apps seem to expect. 2) The GnuTLS documentation and API has a flag to enable V1 CAs to be valid as a CA root, and another flag to enable V1 CAs to be valid as an intermediate CA cert. This implies the default is that the certs are intended to be disallowed. I see that as a reason to patch, not a reason not to patch. -- 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
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
Edward Allcutt emall...@gleim.com writes: Package: libgnutls13 Version: 1.4.4-3+etch3 Severity: important After the upgrade all embedded uses of LDAP fail with connection errors. On investigations these seem to be caused by certificate validation problems. This was first noticed with nss_ldap. After enabling debugging, running `getent group` produced error messages like: TLS certificate verification: depth: 0, err: 130, subject: snip DN/ TLS certificate verification: Error, Unknown error Similar problems occur for pam_ldap and apache mod_authnz_ldap. Strangely, gnutls-cli verifies the server certificate with no problems. The error was first seen in a STARTTLS only configuration. I have since enabled ldaps to ease testing with gnutls-cli and confirmed it still affects nss_ldap and apache switched to ldaps. The root (trusted) certificate of our cert chain is an x509v1 cert, however I'd expect gnutls-cli to complain if this were the issue. Please post output from 'gnutls-cli -p 663 your.ldap.server -d 4711 --print-cert' replacing your.ldap.server as appropriate. I suspect the problem is that you have a RSA-MD5 signature somewhere in the certificate chain. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
tags 514807 wontfix thanks Edward Allcutt emall...@gleim.com writes: Simon Josefsson wrote: Edward Allcutt emall...@gleim.com writes: Package: libgnutls13 Version: 1.4.4-3+etch3 Severity: important After the upgrade all embedded uses of LDAP fail with connection errors. On investigations these seem to be caused by certificate validation problems. This was first noticed with nss_ldap. After enabling debugging, running `getent group` produced error messages like: TLS certificate verification: depth: 0, err: 130, subject: snip DN/ TLS certificate verification: Error, Unknown error Similar problems occur for pam_ldap and apache mod_authnz_ldap. Strangely, gnutls-cli verifies the server certificate with no problems. The error was first seen in a STARTTLS only configuration. I have since enabled ldaps to ease testing with gnutls-cli and confirmed it still affects nss_ldap and apache switched to ldaps. The root (trusted) certificate of our cert chain is an x509v1 cert, however I'd expect gnutls-cli to complain if this were the issue. Please post output from 'gnutls-cli -p 663 your.ldap.server -d 4711 --print-cert' replacing your.ldap.server as appropriate. Output of `gnutls-cli -p ldaps -d 4711 --print-cert ldap-3.teamgleim.com out 21` attached. I suspect the problem is that you have a RSA-MD5 signature somewhere in the certificate chain. Nope, already checked that... gnutls-cli does work after all. It's the other modules linked to libgnutls that are failing. I believe the problem is that you have a V1 CA, which isn't permitted by default by libgnutls. The reason gnutls-cli doesn't complain is because it contains this code: /* there are some CAs that have a v1 certificate *%@#*% */ gnutls_certificate_set_verify_flags (xcred, GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT); 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. For explanation of why V1 CA's are bad, see: http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3365 I'm tagging this as wontfix since this is the documented and intended behaviour. I am sorry you had to notice it through an upgrade -- however the reason for the upgrade was to close this hole. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
Simon Josefsson si...@josefsson.org writes: The reason gnutls-cli doesn't complain is because it contains this code: /* there are some CAs that have a v1 certificate *%@#*% */ gnutls_certificate_set_verify_flags (xcred, GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT); 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. FWIW, I've worked on this in the gnutls 2.7.x branch. gnutls-cli no longer accepts V1 CAs by default, and there is a new --priority token %VERIFY_ALLOW_X509_V1_CA_CRT to enable it for those that needs it. The priority string approach is what we recommend applications expose to their users for configuring GnuTLS internal details. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
Simon Josefsson wrote: Simon Josefsson si...@josefsson.org writes: The reason gnutls-cli doesn't complain is because it contains this code: /* there are some CAs that have a v1 certificate *%@#*% */ gnutls_certificate_set_verify_flags (xcred, GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT); 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. FWIW, I've worked on this in the gnutls 2.7.x branch. gnutls-cli no longer accepts V1 CAs by default, and there is a new --priority token %VERIFY_ALLOW_X509_V1_CA_CRT to enable it for those that needs it. The priority string approach is what we recommend applications expose to their users for configuring GnuTLS internal details. That's all very well, but it's a rather big change in functionality for stable. I doubt it would be acceptable to patch all the relevant apps which assume that their list of trusted CAs will actually be used as such. I can see the same change has been made in libgnutls26 in lenny. Should I file several RC bugs against the various modules affected? Bear in mind that their documented semantics are a list of trusted CAs so I think GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT would be entirely appropriate in those cases. Are there any apps which provide a list of trusted certs which should not all be considered trusted CAs? If not then perhaps GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT should be the default. -- 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
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
retitle 514807 X.509v1 CA certs no longer trusted implicitly thanks Simon Josefsson wrote: Edward Allcutt emall...@gleim.com writes: Simon Josefsson wrote: I suspect the problem is that you have a RSA-MD5 signature somewhere in the certificate chain. Nope, already checked that... gnutls-cli does work after all. It's the other modules linked to libgnutls that are failing. 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? 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. 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. In addition, at least one very popular CA still seems to use a v1 cert as their root. They have new v3 root certs however these aren't included in ca-certificates until lenny. I'm tagging this as wontfix since this is the documented and intended behaviour. I am sorry you had to notice it through an upgrade -- however the reason for the upgrade was to close this hole. Hmm, I thought the reason for the upgrade was to close this hole: CVE-2008-4989. Fixing this deviation from documentation was just a side-effect. -- 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
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
Package: libgnutls13 Version: 1.4.4-3+etch3 Severity: important After the upgrade all embedded uses of LDAP fail with connection errors. On investigations these seem to be caused by certificate validation problems. This was first noticed with nss_ldap. After enabling debugging, running `getent group` produced error messages like: TLS certificate verification: depth: 0, err: 130, subject: snip DN/ TLS certificate verification: Error, Unknown error Similar problems occur for pam_ldap and apache mod_authnz_ldap. Strangely, gnutls-cli verifies the server certificate with no problems. The error was first seen in a STARTTLS only configuration. I have since enabled ldaps to ease testing with gnutls-cli and confirmed it still affects nss_ldap and apache switched to ldaps. The root (trusted) certificate of our cert chain is an x509v1 cert, however I'd expect gnutls-cli to complain if this were the issue. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-xen-amd64 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Versions of packages libgnutls13 depends on: ii libc6 2.3.6.ds1-13etch8 GNU C Library: Shared libraries ii libgcrypt111.2.3-2 LGPL Crypto library - runtime libr ii libgpg-error0 1.4-1 library for common error values an ii liblzo11.08-3data compression library (old vers ii libopencdk80.5.9-2 Open Crypto Development Kit (OpenC ii libtasn1-3 0.3.6-2 Manage ASN.1 structures (runtime) ii zlib1g 1:1.2.3-13compression library - runtime libgnutls13 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
