Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
On 10/07/15 19:34, R C Delgado wrote: > Hello, > > One further question. Can you please confirm that the alternative > certificate chain feature is enabled by default? It seems to be implied > in all emails regarding this matter, and I'm assuming the Advisory email > would have mentioned it otherwise. Yes, it is enabled by default. Matt > > I've searched the OpenSSL code and seen that X509_V_FLAG_NO_ALT_CHAINS > exists but is not set in the "flags" member by default when a new X509 > context is initialised. And my code does not modify the context to > include this flag. > > Please let me know if I'm missing something. > > (I'm using OpenSSL 1.0.1o) > > Many thanks, > RCD > > > > > > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
Hello, One further question. Can you please confirm that the alternative certificate chain feature is enabled by default? It seems to be implied in all emails regarding this matter, and I'm assuming the Advisory email would have mentioned it otherwise. I've searched the OpenSSL code and seen that X509_V_FLAG_NO_ALT_CHAINS exists but is not set in the "flags" member by default when a new X509 context is initialised. And my code does not modify the context to include this flag. Please let me know if I'm missing something. (I'm using OpenSSL 1.0.1o) Many thanks, RCD > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
Thank you very much. It really helps. On Fri, Jul 10, 2015 at 2:32 PM, Matt Caswell wrote: > > > On 10/07/15 13:09, R C Delgado wrote: > > Hello, > > > > With regards to CVE-2015-1793, I've seen the example in > verify_extra_test.c. > > How deep does the certificate chain have to be? > > If I have 2 self-signed CA certificates, and a non-CA certificate is > > received for verification, will this hit the problem? > > > > Also, is it a condition of the bug that both CA certificates have to > > have the same subject names and keys, as suggested in the file? > > > The conditions for triggering the bug are a little complicated, but I'll > do my best to explain it. > > Under normal circumstances things work as follows: > > We are provided with a certificate to verify from a remote peer. Lets > call the certificate we are trying to verify Leaf. > As well as Leaf that has been provided from the remote peer, they also > supply us with a set of untrusted certs. > Finally we also have a store of trusted certs. > > OpenSSL will first attempt to build a certificate chain. The chain > building works as follows (much simplified): > > 1. Set Leaf as the top of the chain > 2. Look for the issuer of the cert at the top of the chain from within > the untrusted set. If we find it add it to the top of the chain > 3. Repeat (2) until we can't find any more certs from the untrusted set > 4. Look for the issuer of the top of the chain from the set of trusted > certs > 5. Repeat (4) until we can't find any more certs from the trusted set > > If we've found a valid chain with a trusted self signed cert at the top, > then we stop there. If not, then we continue to look to see if there is > an alternative chain that can be built. This works as follows: > > Pop all the trusted certs off the top of the chain, then start popping > the untrusted certs off. Each time we pop an untrusted cert off start > the chain building again from step 4. > > The bug occurs when during the initial chain building: > 1) We have added at least one cert from the untrusted set > 2) We have added at least one cert from the trusted store > > For 1.0.2 there is the additional condition: > 3) After doing (1) and (2) above we do not have a valid chain > > Finally (for both 1.0.1 and 1.0.2) > 4) After popping off at least one untrusted cert from the chain we can > build an alternative valid chain > > Under the above conditions the end entity cert Leaf could "issue" a new > certificate even though it is not supposed to (I'll call that invalid > certificate "Bad"). > > So these certs would need to be present (at a minimum): > > Chain 1: > > Trusted Cert 1 > | > Untrusted Cert 1 > | > Leaf > | > Bad > > Chain 2: > > Trusted Cert 2 > | > Leaf > | > Bad > > There are other possible longer chains, but this is the minimum set. For > 1.0.2, Chain 1 would have to be non-trusted, even though we have added a > trusted cert. This can occur if Trusted Cert 1 is not self signed and > its issuer is not in the trusted store. For 1.0.1 any chain will do. > Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers > of Leaf (i.e. they have the same subject names and public keys). Chain 2 > must be trusted (so Trusted Cert 2 has to be a self-signed root). > > Matt > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
On 07/10/2015 09:32 AM, Matt Caswell wrote: On 10/07/15 13:09, R C Delgado wrote: Hello, With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. How deep does the certificate chain have to be? If I have 2 self-signed CA certificates, and a non-CA certificate is received for verification, will this hit the problem? Also, is it a condition of the bug that both CA certificates have to have the same subject names and keys, as suggested in the file? The conditions for triggering the bug are a little complicated, but I'll do my best to explain it. So these certs would need to be present (at a minimum): Chain 1: Trusted Cert 1 | Untrusted Cert 1 | Leaf | Bad Chain 2: Trusted Cert 2 | Leaf | Bad There are other possible longer chains, but this is the minimum set. For 1.0.2, Chain 1 would have to be non-trusted, even though we have added a trusted cert. This can occur if Trusted Cert 1 is not self signed and its issuer is not in the trusted store. For 1.0.1 any chain will do. Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers of Leaf (i.e. they have the same subject names and public keys). Chain 2 must be trusted (so Trusted Cert 2 has to be a self-signed root). Thanks, Matt. This is the most cogent explanation I've seen to date. Cheers -- Lewis - Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA Rosenthal & Rosenthal, LLCwww.2rosenthals.com visit my IT blogwww.2rosenthals.net/wordpress IRS Circular 230 Disclosure applies see www.2rosenthals.com - ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
On 10/07/15 13:09, R C Delgado wrote: > Hello, > > With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. > How deep does the certificate chain have to be? > If I have 2 self-signed CA certificates, and a non-CA certificate is > received for verification, will this hit the problem? > > Also, is it a condition of the bug that both CA certificates have to > have the same subject names and keys, as suggested in the file? The conditions for triggering the bug are a little complicated, but I'll do my best to explain it. Under normal circumstances things work as follows: We are provided with a certificate to verify from a remote peer. Lets call the certificate we are trying to verify Leaf. As well as Leaf that has been provided from the remote peer, they also supply us with a set of untrusted certs. Finally we also have a store of trusted certs. OpenSSL will first attempt to build a certificate chain. The chain building works as follows (much simplified): 1. Set Leaf as the top of the chain 2. Look for the issuer of the cert at the top of the chain from within the untrusted set. If we find it add it to the top of the chain 3. Repeat (2) until we can't find any more certs from the untrusted set 4. Look for the issuer of the top of the chain from the set of trusted certs 5. Repeat (4) until we can't find any more certs from the trusted set If we've found a valid chain with a trusted self signed cert at the top, then we stop there. If not, then we continue to look to see if there is an alternative chain that can be built. This works as follows: Pop all the trusted certs off the top of the chain, then start popping the untrusted certs off. Each time we pop an untrusted cert off start the chain building again from step 4. The bug occurs when during the initial chain building: 1) We have added at least one cert from the untrusted set 2) We have added at least one cert from the trusted store For 1.0.2 there is the additional condition: 3) After doing (1) and (2) above we do not have a valid chain Finally (for both 1.0.1 and 1.0.2) 4) After popping off at least one untrusted cert from the chain we can build an alternative valid chain Under the above conditions the end entity cert Leaf could "issue" a new certificate even though it is not supposed to (I'll call that invalid certificate "Bad"). So these certs would need to be present (at a minimum): Chain 1: Trusted Cert 1 | Untrusted Cert 1 | Leaf | Bad Chain 2: Trusted Cert 2 | Leaf | Bad There are other possible longer chains, but this is the minimum set. For 1.0.2, Chain 1 would have to be non-trusted, even though we have added a trusted cert. This can occur if Trusted Cert 1 is not self signed and its issuer is not in the trusted store. For 1.0.1 any chain will do. Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers of Leaf (i.e. they have the same subject names and public keys). Chain 2 must be trusted (so Trusted Cert 2 has to be a self-signed root). Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
>How deep does the certificate chain have to be? It does not matter. >If I have 2 self-signed CA certificates, and a non-CA certificate is received >for verification, will this hit the problem? >Also, is it a condition of the bug that both CA certificates have to have the >same subject names and keys, as suggested in the file? I think you are confused. The bug is not about CA's. It's about a non-CA fooling the runtime into treating it as if it were a CA and being able to issue a certificate. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory - CVE-2015-1793
Hello, With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. How deep does the certificate chain have to be? If I have 2 self-signed CA certificates, and a non-CA certificate is received for verification, will this hit the problem? Also, is it a condition of the bug that both CA certificates have to have the same subject names and keys, as suggested in the file? Many thanks for your help. RCD ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
