On Fri May 29 05:40:51 2015, [email protected] wrote: > On 5/27/2015 4:21 AM, Matt Caswell via RT wrote: > > On Wed May 27 06:41:51 2015, [email protected] wrote: > >> On 3/16/2015 5:45 AM, Kai Engert via RT wrote: > >>> Thank you very much for your work on this issue! > >>> In my testing so far, it works as requested. > >>> > >>> I noticed the code changes in x509_vfy.c apply fine on top of the > 1.0.2 > >>> stable branch, and the test suite succeeeds. > >>> > >>> Will you consider to add this enhancement in a feature release on > the > >>> 1.0.2 branch? > >> I second this. It looks like this is also discussed in bug #2634 > where > >> it was considered an enhancement and therefore will not be in > 1.0.2. It > >> seems more like a bug fix to me though. If OpenSSL can complete the > >> chain it should. What would be the disadvantage of doing so? > > This issue is now being treated as a bug fix and the fix was already > applied to > > the 1.0.2 tree a while ago (and therefore will appear in the next > 1.0.2 > > release). A backport for 1.0.1 also exists but has not yet hit the > repo. > > > > Matt > > Thanks Matt. TRUSTED_FIRST flag has been brought up a few times on > curl-library and we are wondering what would be the disadvantages if > we > added it to our default flags? Also, the alt chain check in x509_vfy.c > isn't done if TRUSTED_FIRST and I'm having trouble grasping why that > is. > Why not check for alternate chains regardless of whether or not you're > checking trusted store first? > >From 1.0.2b onwards OpenSSL will support three different strategies for achieving the goal of building a valid certificate chain:
1) Old style 2) Trusted first 3) Alt chains With old style (all current versions of OpenSSL) we start with the peer provided certificate, then we add as many certificates to the chain as we can from the list provided by the peer. Finally we add as many as we can from the trusted certificate store. If we end up with a valid chain then we have been successful. >From 1.0.2 we additionally support the trusted first strategy (although this is not the default). In this strategy we start with the peer provided certificate and then see if we can add certificates from the trusted store to build a chain. If we can then great - we're done. Otherwise we add a certificate from the peer provided list and then check the trusted store again, and so on until we have either found a chain or run out of peer provided certificates to add. We considered making trusted first the default strategy however there is a problem with this. The trusted store logic will cache certificates that we look up. However we only cache *success* but not *failure*. Therefore there is a potential performance hit every time we go through the trusted store but fail to find any certificates. The trusted first strategy could end up doing this a lot. Its unclear exactly how big this performance hit is - but that is the reason why we were wary of making this the default. >From 1.0.2b we will also support the alt chains strategy (and this will be the default). This starts off in exactly the same way as the old style approach. However if after adding all the certificates from the peer provided list we are unable to build a trusted chain, then we pop the last certificate off the chain we've built so far and go back to the trusted store to have another go. We continue this until we've got no more certificates to pop. The primary advantage of the alt chains strategy is that there is no performance hit over any chain that would be successfully built using the old style strategy (because it starts off in the same way). There might be a performance hit on unsuccessful chain building over the old style - but we assume this is less of an issue. It makes no sense to combine the trusted first and alt chains strategies. With trusted first we have already checked all of the possible chains by the time we get to the end of the peer provided list - so there is no point in then popping certs off the top of our chain and checking the trusted store again. Hope that clarifies things, Matt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
