tree e70a5bf03cf5a5c2429a5f177ae484fa94454384
parent 23c4ee2a9f07c3abb12367fb14ba6424092940a1
author David Benjamin <davidben@google.com> 1629832318 -0400
committer Pete Bentley <prb@google.com> 1633687214 +0100

Enable X509_V_FLAG_TRUSTED_FIRST by default.

Cherry-picked into mainline-prod from AOSP, see below for
AOSP and upstream notes.

Due to time elapsed since last full BoringSSL merge into
mainline-prod, this CL also includes some extra header file
definitions from upstream. These have no functional impact
but are needed to support the extra tests in this CL.

AOSP Cherry-pick notes:
Cherry-picked into AOSP from
https://boringssl-review.googlesource.com/c/boringssl/+/49745
and
https://boringssl-review.googlesource.com/c/boringssl/+/49746

Cherry-picked outside normal BoringSSL release process to allow
easier cherry-picking to Mainline (see bug for details).

The first cherry-pick is a test-only fix to pick up correct defaults,
the rest of this commit message refers to the second.

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.

BoringSSL-Bug: 439
Bug: 201667701
Test: atest boringssl_crypto_test
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49746
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
(cherry picked from BoringSSL commit 8f5eb80b810ff63d14ad3535cb16f7cb8271a4f5)

Change-Id: Ib75feb0081ced6520f9547ff381ee7b4dee75010
Merged-In: Ib75feb0081ced6520f9547ff381ee7b4dee75010
(cherry picked from commit 7c27ee0dbbee0eedaa53f0a863ab5d70a3be3327)