mirror of
https://github.com/curl/curl.git
synced 2026-08-25 01:23:31 +03:00
ECH: enable support for the AWS-LC backend
Extend existing ECH support for BoringSSL to its AWS-LC fork. Also enable ECH in AWS-LC CI jobs. ``` curl 8.11.0-DEV (x86_64-pc-linux-gnu) libcurl/8.11.0-DEV AWS-LC/1.37.0 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libpsl/0.21.2 Release-Date: [unreleased] Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss Features: alt-svc AsynchDNS brotli ECH HSTS HTTPS-proxy IPv6 Largefile libz NTLM PSL SSL threadsafe UnixSockets zstd ``` Closes #15499
This commit is contained in:
parent
cbafcec50b
commit
1cd745a581
4 changed files with 33 additions and 33 deletions
20
docs/ECH.md
20
docs/ECH.md
|
|
@ -8,8 +8,8 @@ SPDX-License-Identifier: curl
|
|||
|
||||
We have added support for ECH to curl. It can use HTTPS RRs published in the
|
||||
DNS if curl uses DoH, or else can accept the relevant ECHConfigList values
|
||||
from the command line. This works with OpenSSL, wolfSSL or BoringSSL as the
|
||||
TLS provider.
|
||||
from the command line. This works with OpenSSL, wolfSSL, BoringSSL or AWS-LC as
|
||||
the TLS provider.
|
||||
|
||||
This feature is EXPERIMENTAL. DO NOT USE IN PRODUCTION.
|
||||
|
||||
|
|
@ -149,7 +149,7 @@ the verbose output, e.g.:
|
|||
```
|
||||
|
||||
At that point, you could copy the base64 encoded value above and try again.
|
||||
For now, this only works for the OpenSSL and BoringSSL builds.
|
||||
For now, this only works for the OpenSSL and BoringSSL/AWS-LC builds.
|
||||
|
||||
## Default settings
|
||||
|
||||
|
|
@ -334,12 +334,12 @@ Then:
|
|||
make
|
||||
```
|
||||
|
||||
The BoringSSL APIs are fairly similar to those in our ECH-enabled OpenSSL
|
||||
fork, so code changes are also in ``lib/vtls/openssl.c``, protected
|
||||
The BoringSSL/AWS-LC APIs are fairly similar to those in our ECH-enabled
|
||||
OpenSSL fork, so code changes are also in ``lib/vtls/openssl.c``, protected
|
||||
via ``#ifdef OPENSSL_IS_BORINGSSL`` and are mostly obvious API variations.
|
||||
|
||||
The BoringSSL APIs however do not support the ``--ech pn:`` command line
|
||||
variant as of now.
|
||||
The BoringSSL/AWS-LC APIs however do not support the ``--ech pn:`` command
|
||||
line variant as of now.
|
||||
|
||||
## wolfSSL build
|
||||
|
||||
|
|
@ -401,7 +401,7 @@ Then there are some functional code changes:
|
|||
The lack of support for ``--ech false`` is because wolfSSL has decided to
|
||||
always at least GREASE if built to support ECH. In other words, GREASE is
|
||||
a compile time choice for wolfSSL, but a runtime choice for OpenSSL or
|
||||
BoringSSL. (Both are reasonable.)
|
||||
BoringSSL/AWS-LC. (Both are reasonable.)
|
||||
|
||||
## Additional notes
|
||||
|
||||
|
|
@ -474,5 +474,5 @@ to get the HTTPS RR and pass the ECHConfigList from that on the command line,
|
|||
if needed, or one can access the value from command line output in verbose more
|
||||
and then reuse that in another invocation.
|
||||
|
||||
Both our OpenSSL fork and BoringSSL have APIs for both controlling GREASE and
|
||||
accessing and logging ``retry_configs``, it seems wolfSSL has neither.
|
||||
Both our OpenSSL fork and BoringSSL/AWS-LC have APIs for both controlling GREASE
|
||||
and accessing and logging ``retry_configs``, it seems wolfSSL has neither.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue