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

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
Enhancement request.

I suggest to enhance the trust chain discovery used by openssl, when
verifying a SSL/TLS server certificate, to make it work with a popular
server configuration.

Recently, Mozilla has started to cleanup the Mozilla CA trust list and
remove CA certificates that use a weaker 1024-bit RSA key. I'll call
them legacy CAs.

When upgrading the trust store used by openssl to exclude the legacy CA
certificates, by default, openssl (e.g. s_client) can no longer verify
the server certificate of several popular SSL/TLS servers, examples are
www.flickr.com and www.amazon.com.

The reason is the approach that CA organizations have used for a smooth
rollover from legacy CA certificates to more recent CA certificates
(with stronger keys). That approach is compatible with the NSS library,
and also with recent versions of the GnuTLS library (e.g. version
3.3.10).

The approach works like explained in the following simplified example.
Let's say we have:
- a legacy CA, self-signed, with issuer/subject name: OLD-CA-1024
- an intermediate CA, with subject name NEW-CA-2048, signed by the
issuer OLD-CA-1024.
- a server certificate, with subject name www.server, signed by the
issuer NEW-CA-2048.

In the past, only OLD-CA-1024 was included in the Mozilla CA trust list.
When the above chain is found, the www.server certificate can be
verified.

In addition to the above, the CA organization creates another
certificate, an alternative version of the NEW-CA-2048 certificate,
which is based on the same public/private key pair, but which is self
signed (issuer and subject names are both NEW-CA-2048).

The CA has worked with Mozilla to get the self-signed version of
NEW-CA-2048 included in the Mozilla trust list. When trusting
NEW-CA-2048, this CA certificate is sufficient to find a valid issuer
chain for www.server.

In practice, the OLD-CA-1024 certificate and the issued certificates
have a remaining lifetime of up to several years, but the web server
configurations are keeping their old configuration. They still send the
intermediate CA version of the NEW-CA-2048 certificate, which is signed
by OLD-CA-1024. This is done for two reasons. First, it is helpful for
enhanced compatibility, the server can work with client software that
trusts OLD-CA-1024, only, and which hasn't been upgraded to trust the
self-signed version of NEW-CA-2048. Second, there are many
administrators who aren't updating their servers, because their server
certificate is still valid.

This means, those servers will keep sending the intermediate CA version
of NEW-CA-2048 in the SSL/TLS handshake.

In order to function correctly with those servers when using the cleaned
up trust list (OLD-CA-1024 removed), it is necessary that client
software attempts to discover more than one version of a trust chain. In
particular, it should be able to ignore an unnecessary intermediate sent
by the server, in order to find a shorter trust path.

However, by default, openssl will not find the shorter path, and will
reject the server certificate, e.g. reporting the inability to get the
issuer certificate.

Unfortunately, this current default behaviour of openssl blocks the
removal of the legacy CA certificates with weaker keys from the CA trust
list, because many existing applications use the openssl default, and
removing the legacy CAs would cause the applications to fail connecting
to the affected servers.

Therefore I'd like to suggest to change the openssl default behaviour,
to make it possible to allow client applications to be compatible with
the above scenario, by upgrading to a newer version of the openssl
library.

When discussing this issue, my colleague Hubert Kario made me aware of a
flag offered by e.g. the openssl s_client utility: "-trusted_first".
When using -trusted_first, the server verification works successfully in
the above scenario.

Given that the suggestion is to change openssl's default behaviour,
changing openssl to use the -trusted_first mode by default might
potentially be a solution. However, it's not obvious if this mode could
have other side effects that are undesirable.

Therefore I suggest to discuss which approach is best to support the
removal of legacy CAs, either by changing the default of the
-trusted_first setting, or by implementing another solution. I think it
would be good to find a solution that could be backported to the openssl
1.0.1 branch.

Thanks in advance for discussing and working on this issue.
Kai


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
On Friday 05 December 2014 15:18:30 you wrote:

> When discussing this issue, my colleague Hubert Kario made me aware of a
> flag offered by e.g. the openssl s_client utility: "-trusted_first".
> When using -trusted_first, the server verification works successfully in
> the above scenario.
>
> Given that the suggestion is to change openssl's default behaviour,
> changing openssl to use the -trusted_first mode by default might
> potentially be a solution. However, it's not obvious if this mode could
> have other side effects that are undesirable.
>
> Therefore I suggest to discuss which approach is best to support the
> removal of legacy CAs, either by changing the default of the
> -trusted_first setting, or by implementing another solution. I think it
> would be good to find a solution that could be backported to the openssl
> 1.0.1 branch.

For what it's worth, I have tested the Alexa top 1 million servers with the
-trusted_first option and haven't found a single server that looses its
trusted status, on the other hand, good few percent of servers do gain it.
That doesn't mean there aren't any (or that I haven't made a mistake in the
tests), but I can't think of a CA structure that would validate correctly with
old mode while not with the new mode (so at least the experiment matches
theory).

More specifically the test was done by setting X509_STORE_set_flags(store,
X509_V_FLAG_TRUSTED_FIRST); during verification. Full code that I used for
testing is available here:
https://github.com/jvehent/cipherscan/blob/master/top1m/parse_CAs.c
https://github.com/jvehent/cipherscan/blob/master/top1m/process-certificate-statistics.sh
(the baseline was achieved by just commenting out the above mentioned line)
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic


_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Salz, Rich

> For what it's worth, I have tested the Alexa top 1 million servers with the -
> trusted_first option and haven't found a single server that looses its trusted
> status, on the other hand, good few percent of servers do gain it.

It's worth a great deal.  Thanks!  I love fact-based analysis. :)
_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT

> For what it's worth, I have tested the Alexa top 1 million servers with the -
> trusted_first option and haven't found a single server that looses its trusted
> status, on the other hand, good few percent of servers do gain it.

It's worth a great deal.  Thanks!  I love fact-based analysis. :)

_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
In reply to this post by Salz, Rich
On Mon, Dec 15, 2014 at 09:23:26AM -0500, Salz, Rich wrote:

> > For what it's worth, I have tested the Alexa top 1 million servers with the -
> > trusted_first option and haven't found a single server that looses its trusted
> > status, on the other hand, good few percent of servers do gain it.
>
> It's worth a great deal.  Thanks!  I love fact-based analysis. :)

This can break DANE TLSA verification, because the site's designated
trust anchor might no longer be in the shorter constructed chain.

It won't break Postfix because it does not support PKIX-TA(0) or
PKIX-EE(1), and with DANE-TA(2), Postfix disables all default CAs
using only the wire chain and any full TA keys from DNS.

However, it could break other applications.  This might include
applications that have specifically configured a short list of CAs
to trust (perhaps just one for a particular peer, rather than the
usual browser bundle).

So this is an incompatible change, and cannot be made in a stable
release (1.0.x).  If this changes in master, this must be prominently
listed in the release notes as an incompatible change.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Tomas Mraz-2
On Po, 2014-12-15 at 14:48 +0000, Viktor Dukhovni wrote:

> On Mon, Dec 15, 2014 at 09:23:26AM -0500, Salz, Rich wrote:
>
> > > For what it's worth, I have tested the Alexa top 1 million servers with the -
> > > trusted_first option and haven't found a single server that looses its trusted
> > > status, on the other hand, good few percent of servers do gain it.
> >
> > It's worth a great deal.  Thanks!  I love fact-based analysis. :)
>
> This can break DANE TLSA verification, because the site's designated
> trust anchor might no longer be in the shorter constructed chain.
>
> It won't break Postfix because it does not support PKIX-TA(0) or
> PKIX-EE(1), and with DANE-TA(2), Postfix disables all default CAs
> using only the wire chain and any full TA keys from DNS.

Yes, this can be possibly broken by this change although I don't believe
there are many (or any at all?) real world cases of such configuration.

> However, it could break other applications.  This might include
> applications that have specifically configured a short list of CAs
> to trust (perhaps just one for a particular peer, rather than the
> usual browser bundle).

Please enlighten me how this case could be broken by this change of
default? If the trust anchor is not found in the trust list, the
intermediate that is sent by the peer is followed anyway.

--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)


_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
On Mon, Dec 15, 2014 at 05:24:03PM +0100, Tomas Mraz wrote:

> > This can break DANE TLSA verification, because the site's designated
> > trust anchor might no longer be in the shorter constructed chain.
> >
> > [Postfix not affected]
>
> Please enlighten me how this case could be broken by this change of
> default? If the trust anchor is not found in the trust list, the
> intermediate that is sent by the peer is followed anyway.

Yes, when a smaller list of trust anchors is employed the
"trusted-first" change does no harm, sorry about any confusion.

The DANE TLSA issue stands.

DANE TLSA PKIX-TA(0) records can designate the digest of a trust
anchor selected by the server operator.  When TLS server transmits
a corresponding certificate chain it may not be safe to replace
that chain with a shorter chain, because the shorter chain may not
employ the designated trust anchor, causing DANE TLSA checks to
fail.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Hubert Kario
On Monday 15 December 2014 16:32:42 Viktor Dukhovni wrote:

> On Mon, Dec 15, 2014 at 05:24:03PM +0100, Tomas Mraz wrote:
> > > This can break DANE TLSA verification, because the site's designated
> > > trust anchor might no longer be in the shorter constructed chain.
> > >
> > > [Postfix not affected]
> >
> > Please enlighten me how this case could be broken by this change of
> > default? If the trust anchor is not found in the trust list, the
> > intermediate that is sent by the peer is followed anyway.
>
> The DANE TLSA issue stands.
>
> DANE TLSA PKIX-TA(0) records can designate the digest of a trust
> anchor selected by the server operator.  When TLS server transmits
> a corresponding certificate chain it may not be safe to replace
> that chain with a shorter chain, because the shorter chain may not
> employ the designated trust anchor, causing DANE TLSA checks to
> fail.

But then why would you use the PKIX chain builder with system root store?

If you use DANE with CA digest, then the server needs to send all
certificates, so you just need to validate the chain you have - you don't have
to build it, you already have it built and in correct order, you just need to
verify signatures and root digest.

If you really want to use the PKIX builder and verifier (to workaround
misconfigured servers), then you search for the cert with matching digest,
load it as trusted, load other certs as untrusted and then try to verify peer
certificate with such trust store.

So it does affect only buggy DANE clients with a root that is signed by other
root (and probably you could even argue about misconfigured DANE records -
missing all valid trust anchors).

--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
On Tue, Dec 16, 2014 at 03:02:22PM +0100, Hubert Kario wrote:

> > DANE TLSA PKIX-TA(0) records can designate the digest of a trust
> > anchor selected by the server operator.  When TLS server transmits
> > a corresponding certificate chain it may not be safe to replace
> > that chain with a shorter chain, because the shorter chain may not
> > employ the designated trust anchor, causing DANE TLSA checks to
> > fail.
>
> But then why would you use the PKIX chain builder with system root store?

With certificate usage PKIX-TA(0) that's exactly what one is supposed
to do.  You're confusing PKIX-TA(0) with DANE-TA(2).

> If you use DANE with CA digest, then the server needs to send all
> certificates, so you just need to validate the chain you have - you don't
> have

See above.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
In reply to this post by Rich Salz via RT
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?

Regards
Kai



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Matt Caswell-2


On 16/03/15 09:45, 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?

Hi Kai

It is our policy to only add defect fixes to released branches. Only in
exceptional circumstances will we add a new feature (usually because of
some security issue). Therefore I think it is highly unlikely that this
will be included in any future 1.0.2 release, and there are no current
plans to do so.

Matt

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Ray Satiro
In reply to this post by Rich Salz via RT
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?

I work on the cURL project and I've encountered this problem twice in
the last month.

The first time was a reporter mentioned an issue connecting to Apache
git-wip-us.apache.org. That looks to be the VeriSign issue discussed in
#2634. The server at the time had sent the old intermediate "VeriSign
Class 3 Public Primary Certification Authority - G5" signed by "Class 3
Public Primary Certification Authority" (VeriSign root legacy) which is
no longer included in the Mozilla bundle. The bundle does include the
newer "VeriSign Class 3 Public Primary Certification Authority - G5"
(now a root) but OpenSSL didn't use it to complete the chain. It looks
like the Apache team fixed the issue [1] by removing the old VeriSign
intermediate. But by doing that clients with an older bundle can no
longer connect.

The second time just this evening, I'm investigating a reported latency
issue (unrelated) with mediafire.com. Its server sends 6 intermediate
certificates and one of the intermediates (actually 2 if you count the
dupe) is a legacy intermediate that is now a root. "thawte Primary Root
CA" sent by the server is signed by "Thawte Premium Server CA" (thawte
root legacy) which is no longer included in the Mozilla bundle. The
bundle does include the newer "thawte Primary Root CA" (now a root) and,
same as above, OpenSSL didn't use it to complete the chain.

Internet Explorer and Firefox handled both verifications correctly, as
one would expect. I understand you may consider the behavior in OpenSSL
< 1.1.0 to be correct but the end result here is that those clients with
the newer bundles are going to fail verify unable to get issuer. There
is a compatible issuer in the bundle. I don't know of any other examples
but I can imagine as legacy certificates are removed the issue could
persist.


[1]: https://issues.apache.org/jira/browse/INFRA-9605

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
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?

I work on the cURL project and I've encountered this problem twice in
the last month.

The first time was a reporter mentioned an issue connecting to Apache
git-wip-us.apache.org. That looks to be the VeriSign issue discussed in
#2634. The server at the time had sent the old intermediate "VeriSign
Class 3 Public Primary Certification Authority - G5" signed by "Class 3
Public Primary Certification Authority" (VeriSign root legacy) which is
no longer included in the Mozilla bundle. The bundle does include the
newer "VeriSign Class 3 Public Primary Certification Authority - G5"
(now a root) but OpenSSL didn't use it to complete the chain. It looks
like the Apache team fixed the issue [1] by removing the old VeriSign
intermediate. But by doing that clients with an older bundle can no
longer connect.

The second time just this evening, I'm investigating a reported latency
issue (unrelated) with mediafire.com. Its server sends 6 intermediate
certificates and one of the intermediates (actually 2 if you count the
dupe) is a legacy intermediate that is now a root. "thawte Primary Root
CA" sent by the server is signed by "Thawte Premium Server CA" (thawte
root legacy) which is no longer included in the Mozilla bundle. The
bundle does include the newer "thawte Primary Root CA" (now a root) and,
same as above, OpenSSL didn't use it to complete the chain.

Internet Explorer and Firefox handled both verifications correctly, as
one would expect. I understand you may consider the behavior in OpenSSL
< 1.1.0 to be correct but the end result here is that those clients with
the newer bundles are going to fail verify unable to get issuer. There
is a compatible issuer in the bundle. I don't know of any other examples
but I can imagine as legacy certificates are removed the issue could
persist.


[1]: https://issues.apache.org/jira/browse/INFRA-9605


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
In reply to this post by Ray Satiro
On Wed May 27 06:41:51 2015, [hidden email] 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

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Ray Satiro
On 5/27/2015 4:21 AM, Matt Caswell via RT wrote:

> On Wed May 27 06:41:51 2015, [hidden email] 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?
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
On 5/27/2015 4:21 AM, Matt Caswell via RT wrote:

> On Wed May 27 06:41:51 2015, [hidden email] 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?


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
In reply to this post by Ray Satiro
On Fri May 29 05:40:51 2015, [hidden email] wrote:

> On 5/27/2015 4:21 AM, Matt Caswell via RT wrote:
> > On Wed May 27 06:41:51 2015, [hidden email] 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