[openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default

Matt Caswell via RT rt at openssl.org
Fri May 29 10:05:13 UTC 2015


On Fri May 29 05:40:51 2015, raysatiro at yahoo.com wrote:
> On 5/27/2015 4:21 AM, Matt Caswell via RT wrote:
> > On Wed May 27 06:41:51 2015, raysatiro at yahoo.com 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



More information about the openssl-dev mailing list