tree 9165209d2283590f4cc03e66951ee0df5d37745f
parent fa2d3d56b9f542f8519b1c2298213d92eb954f3c
author David Benjamin <davidben@google.com> 1617432902 -0400
committer Adam Langley <agl@google.com> 1617899384 +0000

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>