tidy-up: sort TLS backends, distros, alphabetically

Also:
- replace stray [Rr]ustls-ffi with Rustls for consistency.
- add AWS-LC to a couple of lists where missing.

Closes #21481

docs/CIPHERS.md

@@ -96,10 +96,10 @@ are NULL ciphers, offering no encryption whatsoever.)
 
 ### TLS 1.2 (1.1, 1.0) cipher suites
 
-Setting TLS 1.2 cipher suites is supported by curl with OpenSSL, LibreSSL,
-BoringSSL, mbedTLS (curl 8.8.0+), wolfSSL (curl 7.53.0+). Schannel does not
-support setting cipher suites directly, but does support setting algorithms
-(curl 7.61.0+), see Schannel notes below.
+Setting TLS 1.2 cipher suites is supported by curl with AWS-LC, BoringSSL,
+LibreSSL, mbedTLS (curl 8.8.0+), OpenSSL, wolfSSL (curl 7.53.0+). Schannel
+does not support setting cipher suites directly, but does support setting
+algorithms (curl 7.61.0+), see Schannel notes below.
 
 For TLS 1.2 cipher suites there are multiple naming schemes, the two most used
 are with OpenSSL names (e.g. `ECDHE-RSA-AES128-GCM-SHA256`) and IANA names

docs/CURLDOWN.md

@@ -97,7 +97,7 @@ option. The available TLS backends are:
 
 - `GnuTLS`
 - `mbedTLS`
-- `OpenSSL` (also covers BoringSSL, LibreSSL, quictls, AWS-LC and AmiSSL)
+- `OpenSSL` (also covers AmiSSL, AWS-LC, BoringSSL, LibreSSL and quictls)
 - `rustls`
 - `Schannel`
 - `wolfSSL`

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, BoringSSL, AWS-LC
-or rustls-ffi as the TLS provider.
+from the command line. This works with AWS-LC, BoringSSL, OpenSSL, Rustls or
+wolfSSL as the TLS provider.
 
 This feature is EXPERIMENTAL. DO NOT USE IN PRODUCTION.
 
@@ -153,7 +153,7 @@ LD_LIBRARY_PATH=$HOME/code/openssl ./src/curl -vvv --ech ecl:AED+DQA8yAAgACDRMQo
 ```
 
 At that point, you could copy the base64 encoded value above and try again.
-For now, this only works for the OpenSSL and BoringSSL/AWS-LC builds.
+For now, this only works for the OpenSSL and AWS-LC/BoringSSL builds.
 
 ## Default settings
 
@@ -338,11 +338,11 @@ WARNING: ECH HTTPSRR enabled but marked EXPERIMENTAL. Use with caution.
 make
 ```
 
-The BoringSSL/AWS-LC APIs are fairly similar to those in our ECH-enabled
+The AWS-LC/BoringSSL 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/AWS-LC APIs however do not support the `--ech pn:` command
+The AWS-LC/BoringSSL APIs however do not support the `--ech pn:` command
 line variant as of now.
 
 ## wolfSSL build
@@ -405,7 +405,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/AWS-LC. (Both are reasonable.)
+AWS-LC/BoringSSL. (Both are reasonable.)
 
 ## Additional notes
 
@@ -471,7 +471,7 @@ 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/AWS-LC have APIs for both controlling GREASE
+Both our OpenSSL fork and AWS-LC/BoringSSL have APIs for both controlling GREASE
 and accessing and logging `retry_configs`, it seems wolfSSL has neither.
 
 ### Testing ECH

docs/FAQ.md

@@ -294,10 +294,10 @@ curl has been written to use a generic SSL function layer internally, and
 that SSL functionality can then be provided by one out of many different SSL
 backends.
 
-curl can be built to use one of the following SSL alternatives: OpenSSL,
-LibreSSL, BoringSSL, AWS-LC, GnuTLS, wolfSSL, mbedTLS, Schannel (native
-Windows) or Rustls. They all have their pros and cons, and we maintain [a TLS
-library comparison](https://curl.se/docs/ssl-compared.html).
+curl can be built to use one of the following SSL alternatives: AWS-LC,
+BoringSSL, GnuTLS, LibreSSL, OpenSSL, mbedTLS, Rustls, Schannel (native
+Windows), or wolfSSL. They all have their pros and cons, and we maintain
+[a TLS library comparison](https://curl.se/docs/ssl-compared.html).
 
 ## How do I upgrade curl.exe in Windows?
 

docs/INSTALL.md

@@ -146,7 +146,7 @@ These options are provided to select the TLS backend to use.
 - AmiSSL: `--with-amissl`
 - GnuTLS: `--with-gnutls`.
 - mbedTLS: `--with-mbedtls`
-- OpenSSL: `--with-openssl` (also for BoringSSL, AWS-LC, LibreSSL, and quictls)
+- OpenSSL: `--with-openssl` (also for AWS-LC, BoringSSL, LibreSSL, and quictls)
 - Rustls: `--with-rustls`
 - Schannel: `--with-schannel`
 - wolfSSL: `--with-wolfssl`
@@ -486,7 +486,7 @@ install `libssl.a` and `libcrypto.a` to `$TOOLCHAIN/sysroot/usr/lib` and copy
 for Android using OpenSSL like this:
 
 ```sh
-# For OpenSSL/BoringSSL. In general, you need to the SSL/TLS layer's transitive
+# For BoringSSL/OpenSSL. In general, you need to the SSL/TLS layer's transitive
 # dependencies if you are linking statically.
 LIBS='-lssl -lcrypto -lc++'
 ./configure --host aarch64-linux-android --with-pic --disable-shared --with-openssl="$TOOLCHAIN/sysroot/usr"

docs/cmdline-opts/ca-native.md

@@ -24,7 +24,7 @@ Use the operating system's native CA store for certificate verification.
 This option is independent of other CA certificate locations set at run time or
 build time. Those locations are searched in addition to the native CA store.
 
-This option works with OpenSSL and its forks (LibreSSL, BoringSSL, etc) on
+This option works with OpenSSL and its forks (BoringSSL, LibreSSL, etc) on
 Windows (Added in 7.71.0) and on Apple OS when libcurl is built with
 Apple SecTrust enabled. (Added in 8.17.0)
 

docs/cmdline-opts/tls-earlydata.md

@@ -20,8 +20,8 @@ Example:
 Enable the use of TLSv1.3 early data, also known as '0RTT' where possible.
 This has security implications for the requests sent that way.
 
-This option can be used when curl is built to use GnuTLS, wolfSSL, quictls and
-OpenSSL as a TLS provider (but not BoringSSL, AWS-LC, or Rustls).
+This option can be used when curl is built to use GnuTLS, OpenSSL, quictls and
+wolfSSL as a TLS provider (but not AWS-LC, BoringSSL, or Rustls).
 
 If a server supports this TLSv1.3 feature, and to what extent, is announced
 as part of the TLS "session" sent back to curl. Until curl has seen such

docs/libcurl/curl_global_sslset.md

@@ -70,11 +70,11 @@ SSL backend names (case-insensitive): GnuTLS, mbedTLS, OpenSSL, Rustls,
 Schannel, wolfSSL
 
 The name "OpenSSL" is used for all versions of OpenSSL and its associated
-forks/flavors in this function. OpenSSL, BoringSSL, LibreSSL, quictls and
-AmiSSL are all supported by libcurl, but in the eyes of curl_global_sslset(3)
-they are all called "OpenSSL". They all mostly provide the same API.
-curl_version_info(3) can return more specific info about the exact OpenSSL
-flavor and version number in use.
+forks/flavors in this function. AmiSSL, AWS-LC, BoringSSL, LibreSSL, OpenSSL
+and quictls are all supported by libcurl, but in the eyes of
+curl_global_sslset(3) they are all called "OpenSSL". They all mostly provide
+the same API. curl_version_info(3) can return more specific info about the
+exact OpenSSL flavor and version number in use.
 
 # struct
 

docs/libcurl/opts/CURLOPT_PROXY_SSL_OPTIONS.md

@@ -58,7 +58,7 @@ Tells libcurl to not accept "partial" certificate chains, which it otherwise
 does by default. This option fails the certificate verification if the chain
 ends with an intermediate certificate and not with a root cert.
 
-Works with OpenSSL and its forks (LibreSSL, BoringSSL, etc). (Added in 7.68.0)
+Works with OpenSSL and its forks (BoringSSL, LibreSSL, etc). (Added in 7.68.0)
 
 Works with Schannel if the user specified certificates to verify the peer.
 (Added in 8.15.0)
@@ -78,9 +78,9 @@ verification. This option is independent of other CA certificate locations set
 at run time or build time. Those locations are searched in addition to the
 native CA store.
 
-Works with wolfSSL on Windows, Linux (Debian, Ubuntu, Gentoo, Fedora, RHEL),
+Works with wolfSSL on Windows, Linux (Debian, Fedora, Gentoo, RHEL, Ubuntu),
 macOS, Android and iOS (added in 8.3.0); with GnuTLS (added in 8.5.0) and with
-OpenSSL and its forks (LibreSSL, BoringSSL, etc) on Windows (Added in 7.71.0).
+OpenSSL and its forks (BoringSSL, LibreSSL, etc) on Windows (Added in 7.71.0).
 
 ## CURLSSLOPT_AUTO_CLIENT_CERT
 

docs/libcurl/opts/CURLOPT_SSL_OPTIONS.md

@@ -56,7 +56,7 @@ Tells libcurl to not accept "partial" certificate chains, which it otherwise
 does by default. This option fails the certificate verification if the chain
 ends with an intermediate certificate and not with a root cert.
 
-Works with OpenSSL and its forks (LibreSSL, BoringSSL, etc). (Added in 7.68.0)
+Works with OpenSSL and its forks (BoringSSL, LibreSSL, etc). (Added in 7.68.0)
 
 Works with Schannel if the user specified certificates to verify the peer.
 (Added in 8.15.0)
@@ -76,9 +76,9 @@ verification. This option is independent of other CA certificate locations set
 at run time or build time. Those locations are searched in addition to the
 native CA store.
 
-Works with wolfSSL on Windows, Linux (Debian, Ubuntu, Gentoo, Fedora, RHEL),
+Works with wolfSSL on Windows, Linux (Debian, Fedora, Gentoo, RHEL, Ubuntu),
 macOS, Android and iOS (added in 8.3.0); with GnuTLS (added in 8.5.0) and with
-OpenSSL and its forks (LibreSSL, BoringSSL, etc) on Windows (Added in 7.71.0).
+OpenSSL and its forks (BoringSSL, LibreSSL, etc) on Windows (Added in 7.71.0).
 
 This works with Rustls on Windows, macOS, Android and iOS. On Linux it is
 equivalent to using the Mozilla CA certificate bundle. When used with Rustls
@@ -98,13 +98,13 @@ could be a privacy violation and unexpected.
 ## CURLSSLOPT_EARLYDATA
 
 Tell libcurl to try sending application data as TLS1.3 early data. This option
-is supported for GnuTLS, wolfSSL, quictls and OpenSSL (but not BoringSSL
-or AWS-LC). It works on TCP and QUIC connections using ngtcp2.
+is supported for GnuTLS, OpenSSL, quictls and wolfSSL (but not AWS-LC or
+BoringSSL). It works on TCP and QUIC connections using ngtcp2.
 This option works on a best effort basis,
 in cases when it was not possible to send early data the request is resent
 normally post-handshake.
 This option does not work when using QUIC.
-(Added in 8.11.0 for GnuTLS and 8.13.0 for wolfSSL, quictls and OpenSSL)
+(Added in 8.11.0 for GnuTLS and 8.13.0 for OpenSSL, quictls and wolfSSL)
 
 # DEFAULT