Allow client hellos from raw bytes

[lrstewart]

Resolved issues:

resolves #3852

Description of changes:

Add a method to create an s2n_client_hello structure from bytes representing a ClientHello.

As part of this change, I refactored the existing s2n_client_hello_parse method so that it only does work that requires a connection or config, like setting conn->client_protocol_version. I moved the pure parsing to a new method called by both the existing s2n_client_hello_parse and my new method.

Call-outs:

• I wonder if I should change "s2n_client_hello_parse_bytes" to just "s2n_client_hello_parse" and rename the internal method to something like "s2n_client_hello_parse_for_connection".
• I went back and forth on whether s2n_client_hello_parse_bytes should return int or a pointer. I think a pointer is the right choice so that it matches s2n_connection_get_client_hello and we never have an uninitialized s2n_client_hello.
• I also updated the grep_simple_mistakes script. The part verifying that we null-checked pointers returned by s2n_stuffer_raw_read was very out of date and checking for macros that no longer exist.

Testing:

I added some basic unit tests for the new methods.
I also integrated the new methods into the ja3 fingerprinting tests, including the known-value tests. This should ensure that client hellos from raw bytes and client hellos from connections don't parse input differently and produce the same JA3.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[raycoll]

If possible, it would be helpful if this function(or another) could guide the caller on how many more bytes are needed to parse the client hello.

I know this can be solved with TLS record parsing in the application, but even that kind of code would ideally live inside of s2n and the application can just supply bytes.

[lrstewart]

At the moment, the use case we have is that customers have complete ClientHello messages, not unparsed records. But I realized the first version didn't actually expect complete ClientHello messages-- I forgot about the message header!

Parsing the client hello from TLS records is an interesting use case, but I think it's out of scope for now. However, in case we want to handle it in the future, I've renamed the function to make it clear that it operates on messages, not records. You're right that records would require a different signature with some way to indicate "partial success".

[maddeleine]

Will this erase the customer's client hello?

[lrstewart]

Good question, it scared me for a minute ;) No, because we've already copied the customer's client hello into the s2n_client_hello's raw message blob. We just erase the random bytes from our copy. But I added a test to verify

I could make the s2n_client_hello_parse_message's bytes parameter const, but that would require us to copy it a second time in order to parse it with any of our stuffer or blob functions, because blobs and stuffers aren't const :/ But maybe the second copy is worth the better signature?

[maddeleine]

const is never helpful to us :(

[lrstewart]

I got a second opinion from @alexw91 and decided to make the function signature correct and use const. This isn't a super performance sensitive API, so the extra copy shouldn't be a problem.