[RFC] OpenSSL accepts invalid server cert chain
I have encountered a server which presents an invalid set of certificates in its TLS handshake. It's presenting four certificates, where the second cert is *not* the issuer of the first cert in the list. The chain from #2-#3-#4 is fine, but #2 isn't actually the issuer of #1. (It just happens to have the same *name* as the issuer of #1; cf. RT#1942). This violates RFC5246 §7.4.2, which says of the certificate_list that: This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. However, the missing intermediate CA *is* found in my local trust database, and OpenSSL verifies the server quite happily using *that*. This seems wrong — surely the handshake should be rejected? Should I submit a patch? I note that GnuTLS *does* reject the server's handshake — and rightly so, as far as I can tell from the RFC. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
RE: [RFC] OpenSSL accepts invalid server cert chain
David, Failing when a server sends the certificates out of order would result in a large % of transactions failing. On platforms other than Windows the order is determined by the server administrator and what order they put them in the configuration. I recommend not changing the behavior here, there are plenty of cases where standards say one strict behavior but clients have to be flexible enough to work around what's really out in the wild and this is just one of them. Also RFC 5280 (chain validation RFC) is designed to work in these cases, so in that respect OpenSSL is RFC compliant. One could potentially propose a patch that would be used by nginx, apache, etc to do chain validation against the configured certificates before sending the certs to ensure that the implementations also send them in order though -- this is what Windows does. Ryan -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of David Woodhouse Sent: Thursday, July 12, 2012 6:36 AM To: openssl-dev@openssl.org Subject: [RFC] OpenSSL accepts invalid server cert chain I have encountered a server which presents an invalid set of certificates in its TLS handshake. It's presenting four certificates, where the second cert is *not* the issuer of the first cert in the list. The chain from #2-#3-#4 is fine, but #2 isn't actually the issuer of #1. (It just happens to have the same *name* as the issuer of #1; cf. RT#1942). This violates RFC5246 §7.4.2, which says of the certificate_list that: This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. However, the missing intermediate CA *is* found in my local trust database, and OpenSSL verifies the server quite happily using *that*. This seems wrong — surely the handshake should be rejected? Should I submit a patch? I note that GnuTLS *does* reject the server's handshake — and rightly so, as far as I can tell from the RFC. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [openssl-dev] [RFC] OpenSSL accepts invalid server cert chain
Le 12/07/2012 15:36, David Woodhouse a écrit : I have encountered a server which presents an invalid set of certificates in its TLS handshake. This is common. Really common. It's presenting four certificates, where the second cert is *not* the issuer of the first cert in the list. The chain from #2-#3-#4 is fine, but #2 isn't actually the issuer of #1. (It just happens to have the same *name* as the issuer of #1; cf. RT#1942). If it has the same name, then it's the same CA. Has it been rekeyed? This violates RFC5246 §7.4.2, which says of the certificate_list that: This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. However, the missing intermediate CA *is* found in my local trust database, and OpenSSL verifies the server quite happily using *that*. As do other toolkits and browsers. This seems wrong — surely the handshake should be rejected? Should I submit a patch? I note that GnuTLS *does* reject the server's handshake — and rightly so, as far as I can tell from the RFC. Does GnuTLS have access to the missing intermediate CA, too? GnuTLS is not really a good example, it doesn't follow X.520 naming, and doesn't enforce the pathLen constraints. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Object Module 2.0 - Compliance with 186-3
On 07/09/2012 03:55 PM, John Foley wrote: According to the NIST web site, the 2.0 FIPS Object Module claims compliance for FIPS 186-3 using the Extra Random Bits method for EC public key generation. The implementation is FIPS 186-3 Section B.4.2, Key Pair Generation by Testing Candidates. The ExtraRandomBits reference is inaccurate. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Object Module 2.0 - Compliance with 186-3
OK, thanks for clarifying this. On 07/12/2012 02:53 PM, Steve Marquess wrote: On 07/09/2012 03:55 PM, John Foley wrote: According to the NIST web site, the 2.0 FIPS Object Module claims compliance for FIPS 186-3 using the Extra Random Bits method for EC public key generation. The implementation is FIPS 186-3 Section B.4.2, Key Pair Generation by Testing Candidates. The ExtraRandomBits reference is inaccurate. -Steve M. attachment: foleyj.vcf
RE: [RFC] OpenSSL accepts invalid server cert chain
If the actual issuing CA is in your trust store and can be shown to have validly issued the server certificate, then by definition you trust that server. Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of David Woodhouse Sent: Thursday, July 12, 2012 9:36 AM To: openssl-dev@openssl.org Subject: [RFC] OpenSSL accepts invalid server cert chain I have encountered a server which presents an invalid set of certificates in its TLS handshake. It's presenting four certificates, where the second cert is *not* the issuer of the first cert in the list. The chain from #2-#3-#4 is fine, but #2 isn't actually the issuer of #1. (It just happens to have the same *name* as the issuer of #1; cf. RT#1942). This violates RFC5246 §7.4.2, which says of the certificate_list that: This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. However, the missing intermediate CA *is* found in my local trust database, and OpenSSL verifies the server quite happily using *that*. This seems wrong — surely the handshake should be rejected? Should I submit a patch? I note that GnuTLS *does* reject the server's handshake — and rightly so, as far as I can tell from the RFC. -- dwmw2
Re: [openssl-dev] [RFC] OpenSSL accepts invalid server cert chain
On Thu, 2012-07-12 at 20:44 +0200, Erwann Abalea wrote: Le 12/07/2012 15:36, David Woodhouse a écrit : I have encountered a server which presents an invalid set of certificates in its TLS handshake. This is common. Really common. It's presenting four certificates, where the second cert is *not* the issuer of the first cert in the list. The chain from #2-#3-#4 is fine, but #2 isn't actually the issuer of #1. (It just happens to have the same *name* as the issuer of #1; cf. RT#1942). If it has the same name, then it's the same CA. Has it been rekeyed? It has a different X509v3 Subject Key Identifier. The Subject Key Identifier of the second cert in the list does not match the Authority Key Identifier of the first cert. It's a broken chain. The server MUST NOT do this. I note that GnuTLS *does* reject the server's handshake — and rightly so, as far as I can tell from the RFC. Does GnuTLS have access to the missing intermediate CA, too? Yes. If the server had *omitted* the invalid intermediate CAs from its handshake and presented only the leaf certificate, GnuTLS would have accepted it. But when the server has blatantly violated the TLS standard, GnuTLS fails validation without checking further. To be honest, I don't care much whether it's accepted or not. The responses so far seem to suggest that accepting it would be a good idea. But what I care most about is that my VPN client behaves consistently whether it's linked against OpenSSL or GnuTLS. It sounds like I should 'fix' the GnuTLS side to accept this, even though it's broken behaviour on the part of the server. Thanks to everyone who replied. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [openssl-dev] [RFC] OpenSSL accepts invalid server cert chain
On 07/12/2012 10:00 PM, David Woodhouse wrote: If it has the same name, then it's the same CA. Has it been rekeyed? It has a different X509v3 Subject Key Identifier. The Subject Key Identifier of the second cert in the list does not match the Authority Key Identifier of the first cert. It's a broken chain. The server MUST NOT do this. sorry, a chain is defined by the names, not by key identifiers. there is strictly no requirement the subject and key identifiers must match. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
