The first thing any deployment will want to monitor is whether ECH was
actually used. Also it's useful if the command-line tool can output
this. (The alert is how the client signals it discarded the connection
due to ECH reject.)
This also disables ECH with the handoff mechanism for now. (The
immediate cause being that ech_accept isn't serialized.) We'll probably
need to make some decisions around the ordering here, since ECH affects
where the true ClientHello is available.
Bug: 275
Change-Id: Ie4559733290e653a514fcd94431090bf86bc3172
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47911
Reviewed-by: Adam Langley <agl@google.com>
gai_strerror is one of the Windows functions which behaves differently
whether UNICODE is defined. See
https://docs.microsoft.com/en-us/windows/win32/intl/conventions-for-function-prototypes
Call gai_strerrorA so that we behave consistently in both modes. This
fixes the build failure in
https://chromium-review.googlesource.com/c/chromium/src/+/2613519.
It also fixes a type error in the connect BIO (built but not used in
Chromium), which wasn't noticed because ERR_add_error_data is a variadic
function and untyped. (The type error won't go out of bounds because
we're interpreting a NUL-terminated WCHAR* as a NUL-terminated char*.
The string will be misinterpreted, but it still will be terminated
either at the NUL WCHAR or, more likely, the upper zero byte of the
first Latin-1 character in the string.)
The ERR_add_error_data call raises the question of which of our char*
strings are UTF-8 and which are the POSIX locale / Windows code page
(when those are not also UTF-8). This CL doesn't address this and only
fixes the character width error. Realistically, calling code tosses
char* to printf so often that non-UTF-8 locales are probably a lost
cause. (Although right now we do not transform any OS error strings, so
tossing them to printf works fine. The outputs of functions like
ASN1_STRING_to_UTF8, not so much.)
Change-Id: Ie789730658829bde90022605ade2c86b8a65c3de
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44964
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
David Benjamin
Adam Langley