| commit | 6810f0e83aeb2f11599f192335eec9577678e03e | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sat Apr 03 02:55:02 2021 -0400 |
| committer | Adam Langley <agl@google.com> | Thu Apr 08 16:29:44 2021 +0000 |
| tree | 9165209d2283590f4cc03e66951ee0df5d37745f | |
| parent | fa2d3d56b9f542f8519b1c2298213d92eb954f3c [diff] |
runner: Ensure helloBytes is always the same as hello.marshal(). 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 <agl@google.com>
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: