diff options
| author | Rushil Mehra <rmehra@cloudflare.com> | 2024-06-06 10:07:43 -0700 |
|---|---|---|
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | 2024-07-16 19:53:12 +0000 |
| commit | d274b1bacdca36f3941bf78e43dc38acf676a1a8 (patch) | |
| tree | 34d30870528869d5fbb2905376972e699efcdaea /fuzz/parse_authority_key_identifier_fuzzer_corpus | |
| parent | b34976cae99f8d1b864dbab31e20fc00d06acb09 (diff) | |
| download | boringssl-master.zip boringssl-master.tar.gz boringssl-master.tar.bz2 | |
This commit solves
https://bugs.chromium.org/p/boringssl/issues/detail?id=714. To
summarize, there are cases where servers will advertise ECH on hostnames
that may, in practice, be unable to actually negotiate e.g. TLS 1.3. To
gracefully handle this case, this commit adds a new return value for the
select_cert_cb that signals to the server that ECH must be disabled. To
accomplish this, we slightly rewind the state machine to instead
handshake with ClientHelloOuter, and clear ech_keys on the handshake
state such that the server hello does not include any retry_configs in
EncryptedExtensions. Clients will take this as a signal that ECH is
disabled on the hostname, and that they should instead handshake without
ECH.
Bug: 42290593
Change-Id: I1806ba052ffbc3e5c46161a1596d125cc5e5a8fc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69087
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Diffstat (limited to 'fuzz/parse_authority_key_identifier_fuzzer_corpus')
0 files changed, 0 insertions, 0 deletions