<div dir="ltr">Thank you very much. It really helps.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 10, 2015 at 2:32 PM, Matt Caswell <span dir="ltr"><<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 10/07/15 13:09, R C Delgado wrote:<br>
> Hello,<br>
><br>
> With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c.<br>
> How deep does the certificate chain have to be?<br>
> If I have 2 self-signed CA certificates, and a non-CA certificate is<br>
> received for verification, will this hit the problem?<br>
><br>
> Also, is it a condition of the bug that both CA certificates have to<br>
> have the same subject names and keys, as suggested in the file?<br>
<br>
<br>
</div></div>The conditions for triggering the bug are a little complicated, but I'll<br>
do my best to explain it.<br>
<br>
Under normal circumstances things work as follows:<br>
<br>
We are provided with a certificate to verify from a remote peer. Lets<br>
call the certificate we are trying to verify Leaf.<br>
As well as Leaf that has been provided from the remote peer, they also<br>
supply us with a set of untrusted certs.<br>
Finally we also have a store of trusted certs.<br>
<br>
OpenSSL will first attempt to build a certificate chain. The chain<br>
building works as follows (much simplified):<br>
<br>
1. Set Leaf as the top of the chain<br>
2. Look for the issuer of the cert at the top of the chain from within<br>
the untrusted set. If we find it add it to the top of the chain<br>
3. Repeat (2) until we can't find any more certs from the untrusted set<br>
4. Look for the issuer of the top of the chain from the set of trusted certs<br>
5. Repeat (4) until we can't find any more certs from the trusted set<br>
<br>
If we've found a valid chain with a trusted self signed cert at the top,<br>
then we stop there. If not, then we continue to look to see if there is<br>
an alternative chain that can be built. This works as follows:<br>
<br>
Pop all the trusted certs off the top of the chain, then start popping<br>
the untrusted certs off. Each time we pop an untrusted cert off start<br>
the chain building again from step 4.<br>
<br>
The bug occurs when during the initial chain building:<br>
1) We have added at least one cert from the untrusted set<br>
2) We have added at least one cert from the trusted store<br>
<br>
For 1.0.2 there is the additional condition:<br>
3) After doing (1) and (2) above we do not have a valid chain<br>
<br>
Finally (for both 1.0.1 and 1.0.2)<br>
4) After popping off at least one untrusted cert from the chain we can<br>
build an alternative valid chain<br>
<br>
Under the above conditions the end entity cert Leaf could "issue" a new<br>
certificate even though it is not supposed to (I'll call that invalid<br>
certificate "Bad").<br>
<br>
So these certs would need to be present (at a minimum):<br>
<br>
Chain 1:<br>
<br>
Trusted Cert 1<br>
|<br>
Untrusted Cert 1<br>
|<br>
Leaf<br>
|<br>
Bad<br>
<br>
Chain 2:<br>
<br>
Trusted Cert 2<br>
|<br>
Leaf<br>
|<br>
Bad<br>
<br>
There are other possible longer chains, but this is the minimum set. For<br>
1.0.2, Chain 1 would have to be non-trusted, even though we have added a<br>
trusted cert. This can occur if Trusted Cert 1 is not self signed and<br>
its issuer is not in the trusted store. For 1.0.1 any chain will do.<br>
Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers<br>
of Leaf (i.e. they have the same subject names and public keys). Chain 2<br>
must be trusted (so Trusted Cert 2 has to be a self-signed root).<br>
<span class="HOEnZb"><font color="#888888"><br>
Matt<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
</div></div></blockquote></div><br></div>