Bug#514807: Regression in libgnutls security update
On 2009-02-24 Florian Weimer f...@deneb.enyo.de wrote: * Simon Josefsson: Florian Weimer f...@deneb.enyo.de writes: Simon, could we make the harmless variant (X.509v1 certificate set as trusted is accepted as a root CA, but intermediate X.509v1 certificates aren't accepted) the default in etch? It may be that the practical problems are more important than the potential security problem here, which would argue for using the patch. This seems to be the case. I would like to apply the following patch to etch and lenny. Any objections? [...] Hello, I have been watching this play out since other people participating in this thread are more knowledgable than me. From what I have read I also think this might the right thing to do. Do you intend to push this through security or proposed updates? sid and squeeze are probably better of with following upstream's policy on that. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
* Andreas Metzler: I have been watching this play out since other people participating in this thread are more knowledgable than me. From what I have read I also think this might the right thing to do. Do you intend to push this through security or proposed updates? I've uploaded changed packages to the security queue, but only containing Simon's patch, without any documentation updates. We still lack a fair number of builds for etch, so it's still time to do something about the documentation. It's less an issue for etch because I doubt that there is a 1.4.4 version with different behavior, but I see that updated documentation would make sense for the lenny version. If you want me to go ahead with the security errata, we can still provide updated documentation via stable-proposed-updates. I've got no particular opinion on the behavior for squeeze yet. If we can implement a more appropriate API (or even just a system-wide configuration option), this would be fine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
* Simon Josefsson: Florian Weimer f...@deneb.enyo.de writes: Simon, could we make the harmless variant (X.509v1 certificate set as trusted is accepted as a root CA, but intermediate X.509v1 certificates aren't accepted) the default in etch? It may be that the practical problems are more important than the potential security problem here, which would argue for using the patch. This seems to be the case. I would like to apply the following patch to etch and lenny. Any objections? diff --git a/lib/gnutls_cert.c b/lib/gnutls_cert.c index 7872f20..fe7ad22 100644 --- a/lib/gnutls_cert.c +++ b/lib/gnutls_cert.c @@ -280,6 +280,7 @@ gnutls_certificate_allocate_credentials (gnutls_certificate_credentials_t * (*res)-verify_bits = DEFAULT_VERIFY_BITS; (*res)-verify_depth = DEFAULT_VERIFY_DEPTH; + (*res)-verify_flags = GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT; return 0; } -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
Florian Weimer f...@deneb.enyo.de writes: * Simon Josefsson: Florian Weimer f...@deneb.enyo.de writes: Simon, could we make the harmless variant (X.509v1 certificate set as trusted is accepted as a root CA, but intermediate X.509v1 certificates aren't accepted) the default in etch? It may be that the practical problems are more important than the potential security problem here, which would argue for using the patch. This seems to be the case. I would like to apply the following patch to etch and lenny. Any objections? No, but please try to make sure documentation is clear about what this modification means for users and developers, since you are deviating from upstream code. The GnuTLS manual will not be consistent with the behaviour people will see with GnuTLS on Debian. Maybe README.Debian or similar is a good place to put this information in? NEWS.Debian? changelog.Debian? Or all of them. Maybe point to a wiki page, that will allow us to provide more information to users in the future. /Simon diff --git a/lib/gnutls_cert.c b/lib/gnutls_cert.c index 7872f20..fe7ad22 100644 --- a/lib/gnutls_cert.c +++ b/lib/gnutls_cert.c @@ -280,6 +280,7 @@ gnutls_certificate_allocate_credentials (gnutls_certificate_credentials_t * (*res)-verify_bits = DEFAULT_VERIFY_BITS; (*res)-verify_depth = DEFAULT_VERIFY_DEPTH; + (*res)-verify_flags = GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT; return 0; } -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
I don't know if there is any hope you may reconsider your decision of not fixing this bug (from my point of view it make sense since it breaks 20% of the certification authorities and introduces a significative change in application behaviour), but in case you do, here are my suggestions: - maintain the ability to refuse v3 certs as AC if they do not have the AC=TRUE attribute, as the current fix does; - but tolerate v1 certs as root ACs (which the current fix doesn't); - refuse v1 certs as intermediate AC chains elements, since this appears to be the most dangerous threat: if an attacker gains access to an AC-validated v1 server cert, he could generate any AC-validated forged certs he wants using the robbed cert as an AC intermediate, and dupe many clients... - put somewhere in the doc (maybe a debconf popup ?) that trusting (and using) v1 server certs is dangerous because they could be hijacked for use as ACs. And let the API and clients change go for a further Debian release. Regards, Benoit Branciard -- Ce message a ete verifie par MailScanner pour des virus ou des polluriels et rien de suspect n'a ete trouve. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
On 02/18/2009 01:50 PM, Benoit Branciard wrote: - maintain the ability to refuse v3 certs as AC if they do not have the AC=TRUE attribute, as the current fix does; I'm assuming you mean CA where you have AC here, right? This is an abbreviation for Certificate Authority - but tolerate v1 certs as root ACs (which the current fix doesn't); This seems to be the only proposed change in functionality; basically you're suggesting that GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set by default. This has the side effect that storing an out-of-band-verified V1 peer (end-entity) certificate in the list of trusted certificates would grant that end entity the ability to act as a CA. - refuse v1 certs as intermediate AC chains elements, since this appears to be the most dangerous threat: if an attacker gains access to an AC-validated v1 server cert, he could generate any AC-validated forged certs he wants using the robbed cert as an AC intermediate, and dupe many clients... Agreed! - put somewhere in the doc (maybe a debconf popup ?) that trusting (and using) v1 server certs is dangerous because they could be hijacked for use as ACs. I think this would be an abuse of debconf, particularly because the warning would make more sense coming from the programs which are relying on undocumented behavior of GnuTLS. That is, programs which believe they are only storing trusted *CA* certificates (and no peer certificates) in the list of trusted certs should already be setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT in order to indicate that preference to the library. If they expect users to store end entity certificates in the trusted list as well, then it would be wise to alert those users, but this is a group that gnutls (as a library) would have a hard time targetting. I'm still torn about how to resolve this, fwiw, because i understand the arguments from both sides. Regards, --dkg signature.asc Description: OpenPGP digital signature
Bug#514807: Regression in libgnutls security update
Simon Josefsson wrote: Florian Weimer f...@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 out. (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 certificates.) 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 installed. 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. -- 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: Regression in libgnutls security update
Florian Weimer f...@deneb.enyo.de writes: * Simon Josefsson: What are the possible channels to communicate to etch users that they will get (intentional) errors from gnutls if they have 1) a V1 certificate in their certificate chains, or 2) have a RSA-MD2/MD5 signature in non-trusted certificates in their chain? Perhaps a wiki page will help to explain the issue better than this bug report e-mail thread can do. 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: (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 certificates.) 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). 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. Furthermore, arguments based on the age of those certificates and the resulting deficiencies are not that convincing because most root certificates share one or more of those flaws. The whole system is a mess and has little to do with security (whatever it is). The lack of accountability and transparency (who owns which root certificates?) and the disregard for cryptographic best practices (on key sizes and rollovers) is quite stunning. I completely agree. /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: Regression in libgnutls security update
GTE CyberTrust Global Root, which we happen to use widely in our institution, also is a version *1* x509 certificate. So the libgnutls13 update broke several of our apps. A quick search among the files in ca-certificates package shows up to 20 version-1 certificates over a total of 102. This is about 20% now-untrusted trustworthy root certificates, how could one regard this as being a harmless routine security update ? -- Ce message a ete verifie par MailScanner pour des virus ou des polluriels et rien de suspect n'a ete trouve. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
* Simon Josefsson: What are the possible channels to communicate to etch users that they will get (intentional) errors from gnutls if they have 1) a V1 certificate in their certificate chains, or 2) have a RSA-MD2/MD5 signature in non-trusted certificates in their chain? Perhaps a wiki page will help to explain the issue better than this bug report e-mail thread can do. 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. Furthermore, arguments based on the age of those certificates and the resulting deficiencies are not that convincing because most root certificates share one or more of those flaws. The whole system is a mess and has little to do with security (whatever it is). The lack of accountability and transparency (who owns which root certificates?) and the disregard for cryptographic best practices (on key sizes and rollovers) is quite stunning. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
Florian Weimer f...@deneb.enyo.de writes: * Simon Josefsson: 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 think it is somewhat debatable if this also applies to the root CA container, where the X.509 structure is just use as a transport for key material. The RSA-MD5 signature does not hurt there Agreed. That is how GnuTLS works now; it doesn't validate signatures in trusted CA certificates. and the DN doesn't really matter, either. The SubjectDN of the CA needs to match the IssuerDN of the next cert in the chain. The risk I see is that someone adds a v1 *server* certificate to the trusted list, without realizing that it will act as a *CA* certificate in this place. Exactly. /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: Regression in libgnutls security update
Daniel Kahn Gillmor d...@fifthhorseman.net writes: One option, of course, is to change the interface of GnuTLS to cleanly separate out trusted peer certificates from trusted CA certificates in the API. This would permit users to specify how they intend to use a given V1 cert. Of course, this would also require an API change, potentially an soname bump, etc. In the absence of such a change, i think it's safer to strongly deprecate V1 certificates (as has been documented for years, if not enforcced), and let applications which choose to treat the trusted certificate list solely as a CA store specify so explicitly with GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT. Agreed. V1 certificates should be deprecated. I believe the best we can achieve is to have a flag that allows callers to ignore the security problem and accept V1 CAs. But we have that, and have had it for a long time. The defaults should be secure. I just added in GnuTLS v2.7.x a priority string flag for this, so if applications are enhanced to use the priority string functionality (not many do yet), users will be able to set the flag easily. See NEWS: ** gnutls-cli: No longer accepts V1 CAs by default during X.509 chain verify. Use --priority NORMAL:%VERIFY_ALLOW_X509_V1_CA_CRT to permit V1 CAs to be used for chain verification. ... ** libgnutls: New priority strings %VERIFY_ALLOW_SIGN_RSA_MD5 ** and %VERIFY_ALLOW_X509_V1_CA_CRT. They can be used to override the default certificate chain validation behaviour. /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: Regression in libgnutls security update
Edward Allcutt emall...@gleim.com writes: 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. I agree here that advance warning would have been good. It was not clear that the security problem that was fixed would have the consequence you reported. Now that you report it, and we analyze it, it is clear that it is the intended consequence. What are the possible channels to communicate to etch users that they will get (intentional) errors from gnutls if they have 1) a V1 certificate in their certificate chains, or 2) have a RSA-MD2/MD5 signature in non-trusted certificates in their chain? Perhaps a wiki page will help to explain the issue better than this bug report e-mail thread can do. Hm possibly we could reconsider the default regarding V1 CAs for etch: maybe you are right that the security problem is less problematic than the solution. Anyway, not my call to make, and I hope others can use this discussion to evaluate what the best outcome is. /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: Regression in libgnutls security update
Florian Weimer f...@deneb.enyo.de writes: Simon, could we make the harmless variant (X.509v1 certificate set as trusted is accepted as a root CA, but intermediate X.509v1 certificates aren't accepted) the default in etch? It is possible to allow V1 certs to be used as roots when validating certificates by default, see untested patch below. I wouldn't agree that it is harmless: if there is a V1 end-entity certificate in the trusted cert list, it will be usable as a CA certificate as well. It may be that the practical problems are more important than the potential security problem here, which would argue for using the patch. I'm not the best person to judge that. If the patch is used, some documentation is needed to alert users that they should not put V1 end entity certificates in their trusted ca list. I wouldn't want to see security incidents because of this trade-off. RFC 5280 has discussion about this: (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 certificates.) GnuTLS has no way to provide this out-of-band knowledge that a V1 certificate is a CA or not. /Simon diff --git a/lib/gnutls_cert.c b/lib/gnutls_cert.c index 7872f20..fe7ad22 100644 --- a/lib/gnutls_cert.c +++ b/lib/gnutls_cert.c @@ -280,6 +280,7 @@ gnutls_certificate_allocate_credentials (gnutls_certificate_credentials_t * (*res)-verify_bits = DEFAULT_VERIFY_BITS; (*res)-verify_depth = DEFAULT_VERIFY_DEPTH; + (*res)-verify_flags = GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT; return 0; } -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
* Simon Josefsson: and the DN doesn't really matter, either. The SubjectDN of the CA needs to match the IssuerDN of the next cert in the chain. I meant it in the sense that no root certificates are revoked after the DN has become invalid because the denoted legal entity has ceased to exist, or someone else has gained access to (or full control over) the key material. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
Florian Weimer wrote: * Edward Allcutt: I believe this is a significant regression in stable because at least one widely used CA (godaddy) still issues certificates with a chain ending in a v1 root (ValiCert Class 2). Are we talking about this certificate? Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 2 Policy Validation Authority, CN=http://www.valicert.com//emailaddress=i...@valicert.com That's the one. It's not just a X.509v1 certificate. It's ten years old, it's just 1024 bits, and ValiCert does not exist anymore as an organization (thus the DN is invalid). I'm not any happier about it than you are, but it seems godaddy are still issuing certs using that root. Simon, could we make the harmless variant (X.509v1 certificate set as trusted is accepted as a root CA, but intermediate X.509v1 certificates aren't accepted) the default in etch? Godaddy appears to have a newer v3 root but I don't know how widely deployed this is. It is not in the etch ca-certificates package for example. Which root are you referring to? They're all available at https://certs.godaddy.com/Repository.go. The main new one seems to be Go Daddy Class 2 CA which is in lenny ca-certificates as /usr/share/ca-certificates/mozilla/Go_Daddy_Class_2_CA.crt The other new one is Starfield Services which is in lenny ca-certificates as /usr/share/ca-certificates/mozilla/Starfield_Class_2_CA.crt Neither of these are in etch, and in fact neither of them seem to have the critical flag set for their X509v3 Basic Constraints, which I've seen mentioned as an issue in other bug reports. -- 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: Regression in libgnutls security update
Dear team, The recent updates for libgnutls fixed CVE-2008-4989. Unfortunately (at least in my opinion) this also subtly changed the semantics of trusted certificate lists. Version 1 X509 certificates in the list are no longer trusted as CAs unless an extra flag is set. Several users of libgnutls (I've had the problem with nss_ldap, pam_ldap and apache2 mod_authnz_ldap) assume that all certificates in the list will be implicitly trusted. See #514807. 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. I believe this is a significant regression in stable because at least one widely used CA (godaddy) still issues certificates with a chain ending in a v1 root (ValiCert Class 2). Godaddy appears to have a newer v3 root but I don't know how widely deployed this is. It is not in the etch ca-certificates package for example. 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. -- 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: Regression in libgnutls security update
Edward Allcutt emall...@gleim.com writes: Dear team, The recent updates for libgnutls fixed CVE-2008-4989. Unfortunately (at least in my opinion) this also subtly changed the semantics of trusted certificate lists. Version 1 X509 certificates in the list are no longer trusted as CAs unless an extra flag is set. 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. Several users of libgnutls (I've had the problem with nss_ldap, pam_ldap and apache2 mod_authnz_ldap) assume that all certificates in the list will be implicitly trusted. See #514807. 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. I believe this is a significant regression in stable because at least one widely used CA (godaddy) still issues certificates with a chain ending in a v1 root (ValiCert Class 2). Godaddy appears to have a newer v3 root but I don't know how widely deployed this is. It is not in the etch ca-certificates package for example. 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 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. /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: Regression in libgnutls security update
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
* Edward Allcutt: I believe this is a significant regression in stable because at least one widely used CA (godaddy) still issues certificates with a chain ending in a v1 root (ValiCert Class 2). Are we talking about this certificate? Certificate: Data: Version: 1 (0x0) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 2 Policy Validation Authority, CN=http://www.valicert.com//emailaddress=i...@valicert.com Validity Not Before: Jun 26 00:19:54 1999 GMT Not After : Jun 26 00:19:54 2019 GMT Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 2 Policy Validation Authority, CN=http://www.valicert.com//emailaddress=i...@valicert.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:ce:3a:71:ca:e5:ab:c8:59:92:55:d7:ab:d8:74: 0e:f9:ee:d9:f6:55:47:59:65:47:0e:05:55:dc:eb: 98:36:3c:5c:53:5d:d3:30:cf:38:ec:bd:41:89:ed: 25:42:09:24:6b:0a:5e:b3:7c:dd:52:2d:4c:e6:d4: d6:7d:5a:59:a9:65:d4:49:13:2d:24:4d:1c:50:6f: b5:c1:85:54:3b:fe:71:e4:d3:5c:42:f9:80:e0:91: 1a:0a:5b:39:36:67:f3:3f:55:7c:1b:3f:b4:5f:64: 73:34:e3:b4:12:bf:87:64:f8:da:12:ff:37:27:c1: b3:43:bb:ef:7b:6e:2e:69:f7 Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption 3b:7f:50:6f:6f:50:94:99:49:62:38:38:1f:4b:f8:a5:c8:3e: a7:82:81:f6:2b:c7:e8:c5:ce:e8:3a:10:82:cb:18:00:8e:4d: bd:a8:58:7f:a1:79:00:b5:bb:e9:8d:af:41:d9:0f:34:ee:21: 81:19:a0:32:49:28:f4:c4:8e:56:d5:52:33:fd:50:d5:7e:99: 6c:03:e4:c9:4c:fc:cb:6c:ab:66:b3:4a:21:8c:e5:b5:0c:32: 3e:10:b2:cc:6c:a1:dc:9a:98:4c:02:5b:f3:ce:b9:9e:a5:72: 0e:4a:b7:3f:3c:e6:16:68:f8:be:ed:74:4c:bc:5b:d5:62:1f: 43:dd It's not just a X.509v1 certificate. It's ten years old, it's just 1024 bits, and ValiCert does not exist anymore as an organization (thus the DN is invalid). So while I understand that there is a problem (and we knew that there was a trade-off to be made when releasing the update), I think this particular root certificate is a bad example if you want to make a point. Simon, could we make the harmless variant (X.509v1 certificate set as trusted is accepted as a root CA, but intermediate X.509v1 certificates aren't accepted) the default in etch? Godaddy appears to have a newer v3 root but I don't know how widely deployed this is. It is not in the etch ca-certificates package for example. Which root are you referring to? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
* Simon Josefsson: 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 think it is somewhat debatable if this also applies to the root CA container, where the X.509 structure is just use as a transport for key material. The RSA-MD5 signature does not hurt there, and the DN doesn't really matter, either. The risk I see is that someone adds a v1 *server* certificate to the trusted list, without realizing that it will act as a *CA* certificate in this place. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
On 02/11/2009 06:05 PM, Florian Weimer wrote: I think it is somewhat debatable if this also applies to the root CA container, where the X.509 structure is just use as a transport for key material. The RSA-MD5 signature does not hurt there, and the DN doesn't really matter, either. The risk I see is that someone adds a v1 *server* certificate to the trusted list, without realizing that it will act as a *CA* certificate in this place. if the trusted certificate list were simply a root CA container, then i'd agree with you that V1 certificates are acceptable there. But that's not how the list is treated (or has ever been treated, to my knowledge) in GnuTLS. I think your last sentence makes it clear what the risks are. GnuTLS declares that the trusted certificate list is for holding *any type of* trusted certificate. If a given trusted certificate is a server (end-entity) cert, then the remote party will be validated if it offers that exact certificate (and if its name matches, and it can prove possession of the corresponding secret key, presumably). If a given trusted certificate is a CA cert, then any certificate chain where the end entity certificate matches the name of the remote party, and which is rooted in the trusted CA cert will be accepted. These are two different ways to use the trusted certificate list, and they are distinguished by the *type* of certificate added to the list. IIUC, Nikos' post indicates that there is no way to distinguish a V1 CA certificate from an end-entity certificate. So adding one to any trusted store is inherently a risky activity, particularly if you're adding a certificate that you expect to be an end-entity instead of a CA. GnuTLS has no way of knowing what the user's intent is here. One option, of course, is to change the interface of GnuTLS to cleanly separate out trusted peer certificates from trusted CA certificates in the API. This would permit users to specify how they intend to use a given V1 cert. Of course, this would also require an API change, potentially an soname bump, etc. In the absence of such a change, i think it's safer to strongly deprecate V1 certificates (as has been documented for years, if not enforcced), and let applications which choose to treat the trusted certificate list solely as a CA store specify so explicitly with GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT. Regards, --dkg signature.asc Description: OpenPGP digital signature
