| commit | 8f5eb80b810ff63d14ad3535cb16f7cb8271a4f5 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Fri Oct 01 16:40:31 2021 -0400 |
| committer | Adam Langley <agl@google.com> | Fri Oct 01 22:11:55 2021 +0000 |
| tree | d15b19c6355548a40e5cbe87cab65ffc792135e2 | |
| parent | 2bde9365fac1da341d7bfa504f032aa3e50a8653 [diff] |
Enable X509_V_FLAG_TRUSTED_FIRST by default.
The OpenSSL X.509 verifier lacks a proper path builder. When there are
two paths available for a certificate, we pick one without looking at
expiry, etc.
In scenarios like one below, X509_V_FLAG_TRUSTED_FIRST will prefer
Leaf -> Intermediate -> Root1. Otherwise, we will prefer
Leaf -> Intermediate -> Root1Cross -> Root2:
Root2
|
Root1 Root1Cross
\ /
Intermediate
|
Leaf
If Root2 is expired, as with Let's Encrypt, X509_V_FLAG_TRUSTED_FIRST
will find the path we want. Same if Root1Cross is expired. (Meanwhile,
if Root1 is expired, TRUSTED_FIRST will break and leaving it off works.
TRUSTED_FIRST does not actually select chains with validity in mind. It
just changes the semi-arbitrary decision.)
OpenSSL 1.1.x now defaults to X509_V_FLAG_TRUSTED_FIRST by default, so
match them. Hopefully the shorter chain is more likely to be correct.
Update-Note: X509_verify_cert will now build slightly different chains
by default. Hopefully, this fixes more issues than it causes, but there
is a risk of trusted_first breaking other scenarios. Those scenarios
will also break OpenSSL 1.1.x defaults, so hopefully this is fine.
Bug: 439
Change-Id: Ie624f1f7e85a9e8c283f1caf24729aef9206ea16
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49746
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
There are other files in this directory which might be helpful: