Thank you very much. It really helps. On Fri, Jul 10, 2015 at 2:32 PM, Matt Caswell <matt at openssl.org> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150710/fa29bfda/attachment.html>
