tree 9bad07e14e25e6d9bdfe4d3576e6bce7d3c95765
parent 943987096f1a20d3e21a9b115b851d048b19ac7c
author David Benjamin <davidben@google.com> 1739309510 -0500
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1739311331 -0800

Fix up ClientHello parser errors

Bob pointed out that the previous CL didn't quiiiite move the errors
around right. I looked at the ssl_parse_client_hello_with_trailing_data
calls but not the SSL_parse_client_hello calls. As a result, we doubled
up some errors.

I'd also missed that we already have SSL_R_CLIENTHELLO_PARSE_FAILED.
That said, which error to use is a little interesting. Some codepaths
used to use SSL_R_DECODE_ERROR and some used
SSL_R_CLIENTHELLO_PARSE_FAILED. Further complicating things is that some
ClientHello error paths are unreachable because only the first time a
ClientHello is parsed matters. But we have the second ClientHello in HRR
and inner ClientHellos to content with. (A TLS connection can have up to
four ClientHellos now!)

I've erred towards picking the more specific one, given this whole mess.

Update-Note: The error when the server cannot parse the ClientHello is
now a bit more specific. This might be visible to server-specific
logging, but will not change what is sent over the wire.

Change-Id: I64a4305968616a9f414d3c95fb4ffbd1cfdc4ecc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/76147
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>