Consolidate TLS backends used by libcurl in cargo to reduce delays in security fixes or enhancements

[x448]

Describe the problem you are trying to solve

Detecting and supporting TLS features in every combination of OS version, OS component version, and Active Directory policy setting can get tricky.

Improvements are made more complex because there are too many TLS backends for libcurl:

• cargo should force strong TLS 1.2 cipher suites to reduce downgrade attacks because crates.io offers many "weak" TLS 1.0-1.2 cipher suites #8113 -- harden TLS 1.2 in cargo against downgrade attacks and weak server settings
• discussed in cargo should force strong TLS 1.2 cipher suites to reduce downgrade attacks because crates.io offers many "weak" TLS 1.0-1.2 cipher suites #8113 -- provide a cipher suites option to specify allowed TLS cipher suites

Schannel has these disadvantages:

• crates.io and Windows 7, 8, and 8.1 are always going to connect with a weak cipher suite. Microsoft might sunset Windows 8 and 8.1 in 2023.

• Active Directory policies can enable/disable cipher suites without the user knowing. This can create support issues and make hardening TLS trickier for cargo.

• Linux and Windows are prevented from having the same syntax for cipher suites.

MacOS 10.14 supports strong TLS 1.2 cipher suites, but I don't know what would happen if the same is specified on various older versions (ignore unknown values, quietly downgrade, or cause error).

Describe the solution you'd like

cargo for Linux, MacOS, and Windows should use OpenSSL and/or LibreSSL for its libcurl backend.

This would eliminate the Schannel disadvantages already mentioned. It would simplify and reduce effort required to harden TLS (#8113) and the same for providing a libcurl cipher suites option in cargo.

Work required for standardizing TLS backend for libcurl can be offset by not having to harden Schannel and Secure Transport against TLS 1.2 downgrade attacks. It's a good opportunity to simplify code and remove roadblocks.

Official curl binary for Windows uses OpenSSL 1.1.1f statically linked. So we can examine its code (if needed) to see how libcurl+OpenSSL is used on Windows. Maybe same for MacOS by looking at homebrew or macports (if needed).

Notes

Pull request in curl-rust to add static OpenSSL option for MacOS and Windows:
alexcrichton/curl-rust#284

Schannel on Windows 7, 8, and 8.1 doesn't support ECDHE_RSA with AES_GCM according to docs.microsoft.com.

Default cipher suites supported by Schannel when not modified by Active Directory policies:

• https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-7
• https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-8
• https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-8-1

crates.io only offers 2 strong TLS 1.2 cipher suites and both use ECDHE_RSA + AES_GCM which isn't supported by Schannel on Windows 7, 8, and 8.1.

(click to expand) 📷 crates.io TLS 1.0-1.2 cipher suites in April 2020 (SSL Report)

[x448]

I updated issue to mention official curl binary for Windows uses OpenSSL 1.1.1f statically linked. So we can examine its code (if needed) to see how libcurl+OpenSSL is used on Windows.

Maybe same for MacOS by looking at homebrew or macports (if needed).

[alexcrichton]

The main reason that we don't do this today is around system certificates. While OpenSSL finds system certificates on Linux pretty well, the system certificates stores on macOS and Windows were historically a bit harder to access. This evaulation, however, was done years ago at this point and things might be quite different now at this point.

@x448 would you be willing to help investigate this to implement this? It'd be great if we could ship a single TLS library on all platforms for sure! Deploying this is likely going to be very tricky since it's only really going to trip up users in "esoteric" setups, but it'd be great if we could have a temporary runtime switch for which TLS library to use to get testing on nightly. This would require implementation work to figure out the issue with system certificate stores and investigate whether a runtime switch is possible. Would you be willing to help out implementing these bits?

[joshtriplett]

I'd love to see this as well. There are many things we could do more easily if we know which backend we're dealing with.

[howard0su]

Do we consider completely replace openssl with rustls?

[joshtriplett]

That'd be perfectly fine, as long as it still uses the system certificate store.

[lu-zero]

Would we replace libcurl with reqwest or hyper while at it?