This improves compatibility with cryptography.io. cryptography.io
doesn't actually care what we return, since the code won't run, but
feigning success seems better than failure. If some application does try
to run this function and checks, returning an error will probably crash
it.

Change-Id: I7a8164753a2f1a7b31dbeb10c7030c5e5fea2bc9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46004
Commit-Queue: David Benjamin <[email protected]>
Commit-Queue: Adam Langley <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

I got the values flipped around. Also cryptography.io wants
EC_GROUP_get_asn1_flag to check a curve's encoding. We (mostly) only
support named curves, so just return OPENSSL_EC_NAMED_CURVE.

Change-Id: I544e76b7380ecd8dceb1df3db4dd4cf5cb322352
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46024
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Update-Note: This removes a function that appears to be unused. It also
hardcodes the use of MD5, so please do not use it.

Change-Id: I67909c6360e4737fc22742592f88b907eb818e96
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45964
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Update-Note:
https://boringssl-review.googlesource.com/c/boringssl/+/44124 made these
functions a no-op, but we kept them around because there were still some
call sites floating around. That code has since been updated, so we can
remove this.

Change-Id: I25d411122d0e7a427eef5ebe8357401c0e5039d4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45984
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

pkcs12_test.cc was getting a bit long. Along the way, embed_test_data.go
needed a fix to work around a syntax quirk of C++.

Change-Id: Ic4a19f77d177ebd607918feb253a08f1f9037981
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46044
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

PKCS#12 is overly general and, among other things, supports disabling
encryption. In practice, the unencrypted form is not widely implemented.
Moreover, even in contexts where cleartext is fine, an unencrypted
PKCS#12 file still requires a password for the mandatory MAC component.
They're not very useful.

However, cryptography.io uses them. Previously, we added support for
parsing these. This CL adds support for creating them too, because now
cryptography.io now also depends on that.

Change-Id: Ib7c4e29615047b6c73f887fea7c80f8844999bb7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46045
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

We aim to eventually make the entire X509 structure opaque, but let's
start small.

Update-Note: I believe this is now safe to do. If there are compile
failures, switch to X509_get0_notBefore, X509_getm_notBefore, and
X509_set1_notBefore, or revert this if I'm wrong and too many callers
still need updating.

Change-Id: I6e9d91630a10ac777e13ebcdeb543b3cbeea6383
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45965
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

OpenSSL classified their behavior as a bug and are fixing it for the
next release. In principle it'd be more compatible to emulate OpenSSL's
bug and undo it when we update OPENSSL_VERSION_NUMBER, but use of
PKCS12_parse is rare and this behavior is confusing, so let's leave it
as-is.

Bug: 250
Change-Id: I5f9825490a8afde67272dfaf476b35dbde94b59c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46064
Reviewed-by: Adam Langley <[email protected]>

This is to help with cryptography.io compatibility. We don't implement
any of the flags (PKCS7_sign checks flags == PKCS7_DETACHED), but
cryptography.io now depends on the constant and PKCS7_SIGNER_INFO type
being available.

(cryptography.io also wants some new functions, but I think it's easier
to stub those out externally for now. If we need to actually enable
those features, we can look at actually implementing more of
PKCS7_sign.)

Change-Id: Id8419e34a68c04d4894417c7d6b13c1952d0bb88
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46084
Commit-Queue: David Benjamin <[email protected]>
Commit-Queue: Adam Langley <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

This will also pull in POLICY_MAPPINGS by way of STACK_OF(T) handling.

Change-Id: I8ddc9547647f8cae3800047eb58e1c83f6ae1085
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46104
Commit-Queue: David Benjamin <[email protected]>
Commit-Queue: Adam Langley <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

Change-Id: I290abd9e48dd4c200f61dd1a7c9acb56a9e2a707
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46105
Commit-Queue: Adam Langley <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

This flag causes the runner to execute the shim with the RR debugger.
See https://rr-project.org/.

Unlike typical debuggers, the RR workflow is to first record a session
and then replay it. The user cannot interact with the debugger while
recording and they replay the session multiple times. For these reasons,
I've opted not to launch xterm like -gdb and -lldb do.

The other difference is that -rr-record restricts the runner to exactly
one test. Otherwise, it's too easy to accumulate a bunch of unwanted
recordings. Also, `rr replay` uses the most recent recording by default,
so it's not very useful for runner to record multiple tests.

Change-Id: I2d29d64df5c4c832e50833325db3500ec2698e76
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46144
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

ASN1_OBJECTs are awkward. Sometimes they are static, when returned from
OBJ_nid2obj, and sometimes they are dynamic, when parsed from
crypto/asn1.

Most structures in crypto/asn1 need to support unknown OIDs and thus
must own their ASN1_OBJECTs. But they also may be initialized with
static ones in various APIs, such as X509_ALGOR_set0. To make that work,
ASN1_OBJECT_free detects static ASN1_OBJECTs and is a no-op.

Functions like X509_ALGOR_set0 take ownership, so OpenSSL has them take
a non-const ASN1_OBJECT*. To match, OBJ_nid2obj then returns a non-const
ASN1_OBJECT*, to signal that it is freeable.

However, this means OBJ_nid2obj's mutability doesn't match its return
type. In the fork, we switched OBJ_nid2obj to return const. But, in
doing so, we had to make X509_ALGOR_set0 and X509_PUBKEY_set0_param take
const ASN1_OBJECT, even though they would actually take ownership of
dynamic ASN1_OBJECTs. There are also a few internal casts with a TODO to
be const-correct.

Neither situation is ideal. (Perhaps a more sound model would be to copy
static ASN1_OBJECTs before putting them in most structs. But that would
not match current usage.) But I think aligning with OpenSSL is the
lesser evil here, since it avoids misleading set0 functions. Managing
ownership of ASN1_OBJECTs is much more common than mutating them. To
that end, I've added a note that ASN1_OBJECTs you didn't create must be
assumed immutable[*].

Update-Note: The change to OBJ_nid2obj should be compatible. The changes
to X509_PUBKEY_set0_param and X509_ALGOR_set0 may require fixing some
pointer types.

[*] This is *almost* honored by all of our functions. The exception is
c2i_ASN1_OBJECT, which instead checks the DYNAMIC flag as part of the
object reuse business. This would come up if we ever embedded
ASN1_OBJECTs directly in structs.

Change-Id: I1e6c700645c12b43323dd3887adb74e795c285b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46164
Commit-Queue: David Benjamin <[email protected]>
Commit-Queue: Adam Langley <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

In order to provide evidence to auditors that high-level functions end
up calling into the FIPS module, provide counters that allow for such
monitoring.

Change-Id: I55d45299f3050bf58077715ffa280210db156116
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46124
Commit-Queue: Adam Langley <[email protected]>
Reviewed-by: David Benjamin <[email protected]>

The representation here is a bit more messy than necessary. In doing so,
clean up the variable names and smooth away two rough edges:

- X509_ALGOR_get0 would leave *out_param_value uninitialized if
  *out_param_type is V_ASN1_UNDEF. Instead, set it to NULL, so callers
  do not accidentally use an uninitialized pointer.

- X509_PUBKEY_set0_param, if key is NULL, would leave the key alone. No
  one calls this function externally and none of the (since removed)
  callers in OpenSSL rely on this behavior. A NULL check here adds a
  discontinuity at the empty string that seems unnecessary here:
  changing the algorithm without changing the key isn't useful.
  (Note the API doesn't support changing the key without the algorithm.)

Note for reviewing: the representation of ASN1_TYPE is specified
somewhat indirectly. ASN1_TYPE uses the ASN1_ANY ASN1_ITEM, which has
utype V_ASN1_ANY. Then you look at asn1_d2i_ex_primitive and asn1_ex_c2i
which peel off the ASN1_TYPE layer and parse directly into the value
field, with a fixup for NULL. Hopefully we can rework this someday...

Change-Id: I628c4e20f8ea2fd036132242337f4dcac5ba5015
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46165
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

Flagged by valgrind.

Change-Id: Ib49297bd483650880207a1efe5e9dff666e458d5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46204
Reviewed-by: Adam Langley <[email protected]>

We already know all the supported curves in runner.go. No sense in
repeating this list in more places than needed. (I'm about to need a
similar construct for -signing-prefs, so I figure it's worth being
consistent.)

This CL also adds a ShimConfig option because others don't support the
same curves we do and will likely run into this quickly.

Change-Id: Id79cea16891802af021b53a33ffd811a5d51c4ae
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46186
Reviewed-by: Adam Langley <[email protected]>

When it is and isn't safe to assume an X509 field is non-NULL seems to
cause some confusion. (I often get requests to add NULL checks when
rewriting calling code.)

X.509 has surprisingly few optional fields, and we generally say
pointers are non-NULL unless documented. But that only works if we
remember to mention the nullable ones.

Change-Id: I18b57a17c9d57c377ea2227347e423f574389818
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46185
Reviewed-by: Adam Langley <[email protected]>

See draft-davidben-tls13-pkcs1-00. The code point is disabled by default
and must be configured in SSL_set_verify_algorithm_prefs and
SSL_set_signing_algorithm_prefs. It is also only defined for TLS 1.3
client certificates and otherwise ignored.

This required reworking the tests a bit since this is the first
signature algorithm that's disabled by default, and the first algorithm
that behaves differently between client and server.

Change-Id: Iac4aa96a4963cbc33688c252e958a572c5c3b511
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46187
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

The build scripts distinguish between normal files and bcm.c fragments
based on whether code is in a subdirectory inside crypto/fipsmodule.

Bug: 401
Change-Id: Ieba88178e4f8e19f020e56e2567d5736a34bb43f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46224
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Get entropy from /dev/urandom on FreeBSD < 12, or getrandom() on FreeBSD
12, per
https://www.freebsd.org/cgi/man.cgi?query=getrandom&sektion=2&format=html

Tested manually with `ninja run_tests` on both FreeBSD 11 and 12.

Change-Id: I72ef54d1a83104d1fbe172fd86f6cd32dacc9819
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46188
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: Adam Langley <[email protected]>

This is a little inconvenient for external users of the test suite. It's
also not very helpful to pass -handshaker-path in build configurations
without a handshaker because there won't be a file there anyway.

Change-Id: I6a8fdcfbbf86288876c4c6fda2a46d32663efb69
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46244
Reviewed-by: Adam Langley <[email protected]>

Change-Id: Id5b5b639023d30a8ebd763d02e1787fbf9d79288
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46245
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: Adam Langley <[email protected]>

In doing so, this switches make_errors.go to take library names as
parameters rather than detecting it from the CWD. (I considered
detecting it, but then we'd need to map evp -> crypto/whatever and
crypto/whatever -> evp in both directions.)

Since crypto/hpke currently sits in the EVP namespace, I've gone ahead
and added that, so it should be easier to define new errors in
crypto/hpke. I've not added crypto/cipher, etc., yet. Moving those will
be a breaking change (consumers that put ERR_LIB_CIPHER and ERR_LIB_EVP
in a switch/case need patches).

Bug: 398
Change-Id: Ibae2afd46e076891fa517c377b540b2e492516f0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46264
Reviewed-by: Adam Langley <[email protected]>

Bug: 275
Change-Id: I724e9315b860e230e8fed92de34d89a875ef043c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46184
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

All our EVP_CIPHERs are deterministic, so there's usually no point in
testing only one direction. Some of the ECB tests were missing free
decryption tests. CTR is the same in both directions, but we ought to
test the API agrees. OFB vectors are doubled up, so we can merge them
together. Plus there are typos in the OFB-AES192.Decrypt tests, also
present upstream, so we weren't actually testing everything we should.

(I haven't removed the direction-specific logic altogether since the
tests imported from nist_cavp rely on it. Though there may be something
to be said for running them both ways since they don't actually double
them up...)

Change-Id: I36a77d342afa436e89ad244a87567e1a4c6ee9dc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46284
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

This reverts commit a3437c0. There was
a miscommunication and it does not seem like we currently need this. If
that changes later, it's in Git and we can bring it back easily.

Change-Id: Ibbce29df2258a2d893d725ab3ee6fd78c5b6cb00
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46286
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

See also 8129ac6ac4c0ca3a488c225cde580ede7dabe874 and
81198bf323ea9deda907714170d329ca7d2ff01f from upstream.

In trying to figure out why ASan (which normally catches overlapping
memcpys) didn't flag this, I noticed that we actually don't have tests
for empty inputs. I've added them to cipher_tests.txt where missing and
fixed a bad assert in ofb.c.

ASan still doesn't flag this because LLVM even requires memcpy handle
dst == src. Still, fixing it is less effort than getting a clear answer
from GCC and MSVC. Though this puts us in the frustrating position of
trying to follow a C rule that our main toolchain and sanitizer disavow.
https://bugs.llvm.org/show_bug.cgi?id=11763
https://reviews.llvm.org/D86993

Change-Id: I53c64a84834ddf5cddca0b3d53a29998f666ea2f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46285
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

This API does not come from OpenSSL, but OpenSSL does not appear to have
any way to get this information. There is X509_get0_pubkey_bitstr, but
that only works for X509 objects, not X509_PUBKEY.

Change-Id: Ifc8be554a4d8cbf830c32b95b953f092980804df
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46304
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

This fixes a bug in ASN1_TYPE_get. Partly imported from upstream's
261ec72d58af64327214a78ca1c54b169ad93c28, though I don't believe
ASN1_TYPE_set was broken per se. There's also a lot more than in that
commit.

I've added a test to ensure we maintain the unused bits invariant
anyway, in case external code relies on it. (The invariant comes from
the pointer being NULL-initialized and from ASN1_primitive_free zeroing
*pval on free.)

Change-Id: I4c0c57519a7628041d81c26cd850317e01409556
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46324
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

One thing of note is the name setters are copying, not
ownership-transfering. They're non-const because currently even
serializing or duplicating a X509_NAME potentially mutates it (ugh).

Change-Id: I5265ea54c776cd9f6bed86870d0505fa3e16c794
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46325
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

PKCS#10 CSRs don't contain extensions but attributes, which are kind of
like extensions, but defined separately. There is an attribute type from
PKCS#9 to embed a list of X.509 extensions inside an attribute, as well
as a Microsoft variant.

X509_REQ_set_extension_nids allowed callers globally reconfigure the set
of attributes recognized as aliases of this extensions attribute.  This
is not used by anyone and not thread-safe. Remove it and only support
the two default attribute types.

From there, document the remaining functions.

Update-Note: This removes a pair of unused functions.
Change-Id: Ic1fc41163996c0c980ba8320b417e444d484aa39
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46326
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

To make the script run with python3, let me replace python2 specific
dict functions to python3 compatible ones.

Change-Id: I85b446234f9a86a02f60eed311e1c747a3ff399b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46364
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

It's now 2021. Hopefully we can at least assume anyone building with
-std=c11 also has a corresponding set of headers. Plus, even if you
don't, Clang seems to provide a header. (So C11 atomics work in
clang-cl.) Also apparently atomics are optional, so this checks
__STDC_NO_ATOMICS__.

This does *not* set C11 as the minimum version. If you build with
-std=c99, we'll silently use the non-atomics implementation. That's a
little magical, so I've kept OPENSSL_C11_ATOMIC as a way to assert that
you really want C11 atomics. Mostly it turns into a -std=c11 && !MSVC
self-assert.

Update-Note: If something fails to compile, we'll revert this and adjust
the check, or add an opt-out, or give up. Also, if building with
-std=c99, consider -std=c11.

Change-Id: I1a8074c367a765c5a0f087db8c250e050df2dde8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46344
Reviewed-by: Adam Langley <[email protected]>

CMake 3.5.0 was released March 8, 2016. Per our five year rule, we
can require that now:
https://cmake.org/pipermail/cmake/2016-March/062947.html

Change-Id: I916fdb66e0356e3a8ffbe1e5fa89f51d99a78546
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46345
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

GCC 4.9.0 was released April 2014, which was well over five years ago.

Change-Id: Ib26d459ed82a7af671b8524a334a6f99eacb003e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46346
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

Bug: 402
Change-Id: I6de879f44f6e3eca26f2f49c500769d944fa9bc0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46404
Reviewed-by: Adam Langley <[email protected]>

Although it is strictly fine to call SHA512_Final in SHA384_Final
(array sizes in C parameters are purely decorational, according to the
language), GCC 11 reportedly checks now and gets upset about the size
mismatch. Use an unsized helper function so all our code matches the
specified bounds.

Unfortunately, the bounds in all the functions are a bit misleading
because SHA512_Final really outputs based on sha->md_len (which Init
function you called) rather than which Final function. I've fixed this
places within a library where we mismatched and added asserts to the
smaller functions. SHA512_Final is assert-less because I've seen lots of
code use SHA384_Init / SHA512_Update / SHA512_Final.

This doesn't fix the SHA256 variant since that is generated by a pile of
macros in a multiply-included file. This is probably a good opportunity
to make that code less macro-heavy.

Update-Note: There is a small chance the asserts will trip something,
but hopefully not since I've left SHA512_Final alone.

Bug: 402
Change-Id: I4c9d579a63ee0a0dea103c19ef219c13bb9aa62c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46405
Reviewed-by: Adam Langley <[email protected]>

Being called on every malloc or free has some non-trivial implications.

Change-Id: I9f18f307a8b43e30dea2e2f3a47d7da0b188e980
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46406
Reviewed-by: Adam Langley <[email protected]>

It's now a year past the February 2020 deadline for removing it. Judging
from b/72831885, it looks like the root cause was addressed.

Change-Id: I8c8b358ef4f4146b41aab2a7163c000fa7306025
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46407
Reviewed-by: Adam Langley <[email protected]>

This wasn't being used and wasn't even set correctly in split handshake
tests.

Change-Id: I03000db8dd3c227ea44e7bacaf3d1341259fae44
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46384
Reviewed-by: Adam Langley <[email protected]>

MSAN doesn't like the counters starting at whatever value malloc
found to be free.

Change-Id: I0968e61e0025db35b82291fde5d1e193aef77c1e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46444
Commit-Queue: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: David Benjamin <[email protected]>

Omitting the extension means we'll never issue tickets, but if the
client were to offer a ticket anyway, RFC8446 4.2.9 says we MUST reject
the ClientHello. It's not clear on what alert to use, but
missing_extension is probably appropriate.

Thanks to Ben Kaduk for pointing this out.

Change-Id: Ie5c720eac9dd2e1a27ba8a13c59b707c109eaa4e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46464
Commit-Queue: David Benjamin <[email protected]>
Commit-Queue: Adam Langley <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

Change-Id: I0ea4c600741c3604d7b3b6df614b40d8c57116e4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46504
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: David Benjamin <[email protected]>

When doing Android FIPS validations one ends up with quite a lot of
different build configurations for ACVP and it's useful to be able to
check that a binary is what you think it is.

Change-Id: Ie5c81f164e6e6903c85ea832a93868f84921e74a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46484
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Do a better job with scopers for fds and posix_spawn_file_actions_t.
There's also no need to make a copy of handshaker_path with strdup.
The non-const parameter are because posix_spawn inherits execve's
C problem: unlike C++, C cannot cast from char *const * to
const char *const *, so POSIX APIs are not const-correct.

Finally, we freely use std::vector and friends in tests, so we don't
actually need to depend on bssl::Array.

Change-Id: I739dcb6b1a2d415d47ff9b2399eebec987aab0bc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46524
Reviewed-by: Adam Langley <[email protected]>

Change-Id: Ie5e41c55e36958af5aabd9e365eb2986a488069e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46525
Reviewed-by: Adam Langley <[email protected]>

This is no longer needed.

Change-Id: Ie6dba524ecccd265f7f80a910b40c0fe1800356b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46526
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

TLS 1.3 works, so no need to exclude version negotiation. We also now
only test QUICTransportParams with QUIC, so there is no need to exclude
it manually. Checking the protocol works as well.

Change-Id: Ie9d33095231a1f9eb74145db5147a287e4fdc930
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46527
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

The delegated credentials bits got stuck in the middle of the handshake
bits.

Change-Id: I522d8a5a5f000de3e329934851ee74fc4ec613a7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46528
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

It's strange to have Serialize/Deserialize methods not inverses of each
other. Split the operation up and move the common parts out of the
subclass.

Change-Id: Iadfa57de19faca411c64b64d2568a78d2eb982e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46529
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

The check for ssl_hs_read_change_cipher_spec didn't do anything. Replace
it with an assert and add some comments since the hs->wait handling is a
little tricky.

Change-Id: I8e62ce3cceca9bed4611cb9d3faf0bfec3d3bdd4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46530
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

The ssl_buffer.cc code handles this, but since outgoing handshake I/O
goes through a different path, it was missing these checks.

Change-Id: I4fed62b435b577645c405d0d995511a58d47a702
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46531
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

Some of our calls handled it and others didn't.

Change-Id: I09f15d3db679954599bcf987d86357b6e12e9b9b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46532
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

It's a little confusing to have load_word_le but actually use size_t
instead of crypto_word_t.

NOTE: on some platforms, notably NaCl, crypto_word_t is larger than
size_t. (Do we still need to support this?) We don't have a good testing
story here, so I tested it by hacking up a 32-bit x86 build to think it
was OPENSSL_64_BIT.

Change-Id: Ia0ce469e86803f22655fe2d9659a6a5db766429f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46424
Reviewed-by: Adam Langley <[email protected]>

We have loads of variations of these. Align them in one set. This avoids
the HOST_* macros defined by md32_common.h, so it'll be a little easier
to make it a more conventional header.

Change-Id: Id47fe7b51a8f961bd87839f8146d8a5aa8027aa6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46425
Reviewed-by: Adam Langley <[email protected]>

It's only used from that file and, given the names defined by it,
probably isn't usable by other files anyway.

Change-Id: Ice205408962ade00c1dcb51406da3ef2fd7f0393
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46426
Reviewed-by: Adam Langley <[email protected]>

BIO_flush may return a negative value, so we shouldn't cast it directly
to bool.

Change-Id: Ibdf688d1a6b4b316069e3b99a8a8b18974ee17ed
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46534
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

We don't support renegotiation on the server anymore. Even if we did, we
wouldn't want to rerun ALPN anyway, and we don't do resumption on
renegotiation.

Change-Id: I43438d084bfe5fbe9b011ae0f53349df1baf6c97
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46533
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

AES_128_GCM is more common than AES_GCM_128 and matches the
specification.

Bug: 275
Change-Id: If3446a38f7bfbe0250d9646e363db29b93e4d231
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46666
Reviewed-by: David Benjamin <[email protected]>
Reviewed-by: Dan McArdle <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

This avoids duplicating some code in client and server. It should also
clean up some ECH test code, which needs to juggle a pair of transcripts
for a brief window.

Change-Id: I4db11119e34b56453f01b5890060b8d4129a25b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46564
Reviewed-by: Adam Langley <[email protected]>

This avoids looking up and passing around the cipherSuite object
everywhere. We don't serialize ClientSessionState and, if we did, we can
simply do the lookup at parsing time.

Change-Id: Ice06e4da6b23ff32988597100e8aaa11b82f23ad
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46565
Reviewed-by: Adam Langley <[email protected]>

In early TLS 1.3 drafts, HelloRetryRequest was a dedicated message type.
Our HelloRetryRequest handling in runner is still based on this. Along
the way, remove the SendServerHelloAsHelloRetryRequest test, since
that's just a generic unexpected message type now.

Change-Id: Idd9c54d0ab66d962657af9a53849c3928f78ce5c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46585
Reviewed-by: Adam Langley <[email protected]>

This is a remnant of when we had various pre-standard TLS 1.3 variants.
runner's logic is now built-in.

Change-Id: I72a2fcef9a94e82fa39fe4be9d60ddd329d212ce
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46604
Reviewed-by: Adam Langley <[email protected]>

Per the comment in writeClientHash, we should writeClientHash before
writeRecord to get the sequence numbers right. Some of the client HRR
bits are still wrong, but I'll fix those as part of tidying up the HRR
path in a later commit.

(This doesn't actually matter because only DTLS uses sequence numbers,
and we don't support DTLS 1.3.)

Change-Id: I4cbc671f524d56c7f970b5ec0bceeb2641625d15
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46624
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

We only need to implement enough of SSL 3.0 to test that the shim does
not.

Change-Id: I25cb48e407f1bc458bbdb3544b9df9fdfbc3d9c9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46625
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

The 'client' and 'server' halves are remnants of SSL 3.0 and Go
(originally) lacking a way to clone hash.Hash. The Go limitation meant
that computing SSL 3.0's proto-HMAC construction mutated the running
hash on Finished, so crypto/tls just maintained two of them.

Without SSL 3.0, this is no longer needed. That, however, leaves us with
having both a crypto.Hash and a hash.Hash, and both can't be named
'hash'. I stepped around this by storing the cipher suite itself and
using cipherSuite.hash().

Change-Id: Ia38880ae446949baa2181d33136c748cf5374664
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46626
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

All the comments say the buffer is only needed in TLS 1.2, but this
doesn't match the code. The code uses the buffer in one place, for ECH,
to avoid copying a hash.Hash. Go does support this, albeit in a *very*
roundabout way.

This is ugly but means we can now properly drop the handshake buffer in
TLS 1.3.

Change-Id: I4a1559a64fcb98ccfbab54de99402fe6f62725a1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46627
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Also avoid unnecessarily stashing a copy of the serialized old
ClientHello.

Change-Id: I699299f0ce767ba059fbb08e8f2140793a649322
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46628
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Matching the Go standard library cipher.AEAD interface, EVP_AEAD, and
the C implementation, put the AAD parameter after plaintext/ciphertext.

Bug: 275
Change-Id: I46804ff0e55a75742016ff6311bbe6fd6d208355
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46665
Reviewed-by: Dan McArdle <[email protected]>
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Re-encoding a message does not necessarily give back the same value.

Bug: 275
Change-Id: I52cddd6152445b70579cbe03525898383bee211d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46644
Reviewed-by: David Benjamin <[email protected]>
Reviewed-by: Dan McArdle <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

The client handshake currently defers creating the finishedHash and
writing things into the transcript, which is a little annoying for ECH.
In preparation for simplifying that, one nuisance is that we retain both
hello and helloBytes, across a long span of code. helloBytes is *almost*
the same as hello.marshal() except:

- When we send a V2ClientHello, helloBytes records that we serialized
  the ClientHello completely differently.

- For the JDK11 workaround tests, helloBytes records that we swapped out
  the ClientHello entirely.

- By the time we finally write helloBytes into the transcript, hello may
  have been updated to the second ClientHello.

This CL resolves the first two issues. It replaces the v2ClientHelloMsg
with an option when serializing the clientHelloMsg, and it has the
ClientHello replacement function return a clientHelloMsg instead of a
[]byte. (This is a little weird because we're conflating parsed and
constructed ClientHellos, but ah well.)

A follow-up CL will remove the differed transcript bits and we'll
actually be able to drop helloBytes.

Change-Id: Ib82ac216604e2c4bf421277e57aa5fd3b4cef161
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46629
Reviewed-by: Adam Langley <[email protected]>

The challenge field, at least per our implementation and OpenSSL, may be
either left-padded or truncated to form the ClientHello random. Test
both cases, as well as an exact match.

Change-Id: Icdedf899ef483225d8ed20580ad15818b5e52e91
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46631
Reviewed-by: Adam Langley <[email protected]>

This is follow-up cleanup work from
https://boringssl-review.googlesource.com/27944.

Change-Id: I39d1bf0bc28540228166389eac378b07a1168e6c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46684
Reviewed-by: Adam Langley <[email protected]>

This removes the now unnecessary virtual calls. Benchmark differences are
mostly positive but probably noise.

Before:
Did 839000 AES-128-CBC-SHA1 (16 bytes) open operations in 2000497us (6.7 MB/sec)
Did 623000 AES-128-CBC-SHA1 (256 bytes) open operations in 2000409us (79.7 MB/sec)
Did 434000 AES-128-CBC-SHA1 (1350 bytes) open operations in 2002909us (292.5 MB/sec)
Did 146000 AES-128-CBC-SHA1 (8192 bytes) open operations in 2000785us (597.8 MB/sec)
Did 82000 AES-128-CBC-SHA1 (16384 bytes) open operations in 2014268us (667.0 MB/sec)

After:
Did 866000 AES-128-CBC-SHA1 (16 bytes) open operations in 2000697us (6.9 MB/sec) [+3.2%]
Did 616000 AES-128-CBC-SHA1 (256 bytes) open operations in 2001403us (78.8 MB/sec) [-1.2%]
Did 432000 AES-128-CBC-SHA1 (1350 bytes) open operations in 2003898us (291.0 MB/sec) [-0.5%]
Did 148000 AES-128-CBC-SHA1 (8192 bytes) open operations in 2006042us (604.4 MB/sec) [+1.1%]
Did 83000 AES-128-CBC-SHA1 (16384 bytes) open operations in 2010885us (676.3 MB/sec) [+1.4%]

Change-Id: I735e99296ca9a1771518c622b8e7e6979a0d30bc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46685
Reviewed-by: Adam Langley <[email protected]>

We currently construct finishedHash fairly late, after we've resolved
HelloRetryRequest. As a result, we need to defer some of the transcript
operations across a large chunk of code.

This is a remnant of earlier iterations of TLS 1.3, when
HelloRetryRequest didn't tell us the cipher suite yet. Now the cipher
suite is known earlier and we can construct the finishedHash object
immediately. In doing so, move HRR handling inside doTLS13Handshake().

This keeps more of TLS 1.3 bits together and allows us to maintain the
HRR bits of the handshake closer to the rest of HRR processing. This
will be useful for ECH which complicates this part of the process with
an inner and outer ClientHello. Finally, this adds a missing check that
the HRR and SH cipher suites match.

Change-Id: Iec149eb5c648973325b190f8a0622c9196bf3a29
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46630
Reviewed-by: Adam Langley <[email protected]>

Change-Id: Id6440b3e2feea0539ac83ee697c9e5aee0709fbd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46664
Reviewed-by: Adam Langley <[email protected]>

This CL adds an initial implementation of the ECH server, with pieces of
the client in BoGo as necessary for testing. In particular, the server
supports ClientHelloInner compression with ech_outer_extensions. When
ECH decryption fails, it can send retry_configs back to the client.

This server passes the "ech-accept" and "ech-reject" test cases in
tls-interop-runner[0] when tested against both the cloudflare-go and nss
clients. For reproducibility, I started with the main branch at commit
707604c262d8bcf3e944ed1d5a675077304732ce and updated the endpoint's
script to pass the server's ECHConfig and private key to the boringssl
tool.

Follow-up CLs will update HPKE to the latest draft and catch us up to
draft-10.

[0]: https://github.com/xvzcf/tls-interop-runner

Bug: 275
Change-Id: I49be35af46d1fd5dd9c62252f07d0bae179381ab
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45285
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Rather than computing kVarianceBlocks, which is hard to reason about,
use a sha1_final_with_secret_suffix abstraction. This lets us separate
reasoning in bytes about the minimum and maximum values of |data_size|
and the interaction with HMAC, separately from the core constant-time
SHA-1 update.

It's also faster. I'm guessing it's the more accurate block counts.

Before:
Did 866000 AES-128-CBC-SHA1 (16 bytes) open operations in 2000697us (6.9 MB/sec)
Did 616000 AES-128-CBC-SHA1 (256 bytes) open operations in 2001403us (78.8 MB/sec)
Did 432000 AES-128-CBC-SHA1 (1350 bytes) open operations in 2003898us (291.0 MB/sec)
Did 148000 AES-128-CBC-SHA1 (8192 bytes) open operations in 2006042us (604.4 MB/sec)
Did 83000 AES-128-CBC-SHA1 (16384 bytes) open operations in 2010885us (676.3 MB/sec)

After:
Did 2089000 AES-128-CBC-SHA1 (16 bytes) open operations in 2000049us (16.7 MB/sec) [+141.3%]
Did 851000 AES-128-CBC-SHA1 (256 bytes) open operations in 2000034us (108.9 MB/sec) [+38.2%]
Did 553000 AES-128-CBC-SHA1 (1350 bytes) open operations in 2002169us (372.9 MB/sec) [+28.1%]
Did 178000 AES-128-CBC-SHA1 (8192 bytes) open operations in 2008596us (726.0 MB/sec) [+20.1%]
Did 98000 AES-128-CBC-SHA1 (16384 bytes) open operations in 2001509us (802.2 MB/sec) [+18.6%]

Confirmed with valgrind tooling that this is still constant-time. In
doing so, I ran into a new nuisance with GCC. In loops where we run
constant_time_lt with a counter value, GCC sometimes offsets the loop
counter by the secret. It cancels it out before dereferencing memory,
etc., but valgrind does not know that x + uninit - uninit = x and gets
upset. I've worked around this with a barrier for now.

Change-Id: Ieff8d2cad1b56c07999002e67ce4e6d6aa59e0d3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46686
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Change-Id: Ib2356f1a6e6ef8bfd5b5469eae9d1bc43dd40895
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46724
Commit-Queue: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: David Benjamin <[email protected]>

Bug: 275
Change-Id: I4ccf7e8385d708326c71a855585583908e82bb2d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46744
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

TLS 1.3 servers should only skip early data if the client offered it.
Our HRR codepath didn't quite get this right. This CL is the minimal fix
for this issue, but I think we should rearrange this logic slightly
rather than deciding to do 0-RTT and then changing our mind. The next CL
will do that.

(This bug does not have any interoperability consequences. When
configured to skip early data, we're happy to vacuously skip over zero
early data records. We were just less strict than we should be.)

Change-Id: Ida42134b92b4df708b2bb959c536580bec454165
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46764
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

We currently determine whether we need HelloRetryRequest at the same
time as resolving key share machinery. That is a little too late for
early data negotiation, so we end up accepting early data and then
clearing it later on in the function. This works but is easy to mess up,
given the preceding CL. There's also some ALPS logic that got this
wrong, but I believe it didn't result in any incorrect behavior.

Instead, this pulls secret computation out of the key_share helper
function, which now just finds the matching key share. We then check
early whether we need HRR, before deciding on early data.

Change-Id: I108865da08addfefed4a7db73c60e11cf4335093
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46765
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

This also fixes a minor bug (that doesn't matter because we don't
implement DTLS 1.3). init_message must be paired with finish_message to
correctly handle the DTLS header.

Change-Id: I4b65c82d4b691d5b77d9e20513983145098d6f8f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46785
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

See also 86a90dc749af91f8a7b8da6628c9ffca2bae3009 from upstream. This
differs from upstream's which treats {NULL, 2} as a valid way to spell
the empty list. (I think this is a mistake and have asked them about
it.)

Upstream's CL also, for them, newly makes the empty list disable ALPN,
when previously they'd disable it but misread it as a malloc failure.
For us, we'd already fixed the misreading due to our switch to
bssl::Array and bssl::Span, but the documentation was odd. This CL
preserves that behavior, but updates the documentation and writes a
test.

Update-Note: SSL_CTX_set_alpn_protos and SSL_set_alpn_protos will now
reject invalud inputs. Previously, they would accept them, but silently
send an invalid ALPN extension which the server would almost certainly
error on.

Change-Id: Id5830b2d8c3a5cee4712878fe92ee350c4914367
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46804
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

Change-Id: I3dfd75c93b3ae83e0a4db643ac7d00d2867fa656
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46704
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: David Benjamin <[email protected]>

The gclient-managed files usually go in .gitignore. I think without it,
we have to redownload it all the time on the bots? Though this also
makes my git status cleaner.

Change-Id: Ic9bac6796bd3dcdea5039bcac39e853d9f12906b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46824
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

'corpora' seems to be more common than 'corpuses' in Chromium code
search, including in libFuzzer's source itself.

Change-Id: I6489b57a4608f47274c4400aac135cbfb991953a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46825
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

Also generate a corpus to unblock the Chromium roll. The build tools
expect there to be a corresponding directory somewhere.

Bug: 275
Change-Id: I7a061ba6625ec57c10b0ae17e68b6b0159c539d4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46826
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: Adam Langley <[email protected]>

It's defined as GCM without a plaintext input, so this is trivial.

Change-Id: Id430e998447e489c2bf2dd5c6541877870104ade
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46844
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: David Benjamin <[email protected]>

Chromium's fuzzer uses a shared library build.

Change-Id: I49a9fef9c0f10694302727d0251005240c30988f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46864
Reviewed-by: Adam Langley <[email protected]>

They still need to be Python-2-compatible until I figure out how to
switch the version used in the CI.

I've left out make_curve25519_tables.py because it's some bytes vs
unicode mess I don't care to figure out. We should just rewrite that in
Go which should also be much faster anyway.

Change-Id: I4446641815315a84c2979b1be1e1949f88cbacf8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46884
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

See go/handshake-hints (internal).

CL originally by Bin Wu <[email protected]>. I just reworked the tests and
tidied it up a bit. This is the start of a replacement for the split
handshakes API. For now, only TLS 1.3 is supported. It starts with an
initial set of hints, but we can add more later. (In particular, we
should probably apply the remote handshaker's extension order to avoid
needing to capability protect such changes.)

Change-Id: I7b6a6dfaa84c6c6e3436d2a4026c3652b8a79f0f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46535
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>