Add `./mach build --with-rustls`

[Darkspirit]

I would like to merge this as an optional feature so everyone can already use it for testing and further development. There were earlier attempts with #17938 and #15329. Legacy TLS versions and DHE have already been disabled for OpenSSL.
Main motivation is doing this for Redox, but other platforms will benefit from it as build option as well, so this doesn't need to be an all-or-nothing decision about whether Servo potentially wanted to keep defaulting to a ton of not-safe-Rust TLS and certificate validation code for specific build targets or not(?).

With ./mach build --with-rustls we get

• Certificate Transparency SCT verification
• HTTP/2 enabled by default
• a lot tested, tidy and safe Rust code

Rustls as a dependency is a blocker for integration of

• Rust's QUIC/HTTP3 implementation: https://github.com/djc/quinn
• DNS-over-HTTPS support: https://github.com/bluejekyll/trust-dns/tree/master/crates/https

Therefore it would be good to develop and test behind a build flag until you have gotten enough confidence to use it by default at the end.

Next steps should be

• Adding Rustls support to the ws crate: housleyjk/ws-rs#285
• Adding feature-gated tokio-rustls server to components/net/tests/main.rs
• Adding a Rustls build to decision_task.py.
• Adding DTLS support to Rustls, so it can be used by Gstreamer's WebRTC implementation: ctz/rustls#40 (there is an inactive PR: ctz/rustls#58)
• Using rustls as the default backend for the Redox target (by policy: Redox prefers safe Rust over unsafe code.)
• Building Servo Linux Nightly by default with Rustls

https://github.com/ctz/rustls is the well received Rust TLS library used by time.cloudflare.com, Baidu, and others. It depends on https://github.com/briansmith/webpki which does certificate validation and is written by the author of the same functionality in Firefox. Both depend on https://github.com/briansmith/ring which originally based on BoringSSL, Google's improved fork of OpenSSL, but was further tidied up and got lots of C and C++ replaced with Rust. These libraries were developed for Servo, based on meetings far in the past. (See wiki.) Ring is also used by Google Fuchsia.

https://blog.cloudflare.com/announcing-cfnts/

We decided to use Rustls over OpenSSL or BoringSSL because of the crate's consistent error codes and default support for authentication that is difficult to disable accidentally.

https://www.zdnet.com/article/a-rust-based-tls-library-outperformed-openssl-in-almost-every-category/
https://twitter.com/BRIAN_____/status/1146187144030896129

Rustls vs OpenSSL: https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html:

• 15% quicker to send data
• 5% quicker to receive data
• 20-40% quicker to full handshake (client)
• 10% quicker to full handshake (server)
• 30-70% quicker to resume (client)
• 10-20% quicker to resume (server)
• Uses <1/2 as much RAM

https://twitter.com/repi/status/1146337760921489408

love it, we nuked our OpenSSL usage at EmbarkStudios
and just use Rustls statically linked in and never want to go back

With Baidu's MesaLink there also exists a wrapper providing an OpenSSL API based on Rustls:
https://www.reddit.com/r/rust/comments/b9gd10/mesalink_10_openssl_c_apis_done_with_rust_10m/

Baidu has been using MesaLink in production with >10M monthly active users as of 12/2018.

---

• ./mach build -d does not report any errors
• ./mach build -d --with-rustls does not report any errors
• ./mach test-tidy does not report any errors

[highfive]

Heads up! This PR modifies the following files:

• @wafflespeanut: python/servo/command_base.py
• @KiChjang: components/net/Cargo.toml, components/net/resource_thread.rs, components/net/http_loader.rs, components/net/connector.rs, components/net/tests/main.rs and 1 more

[jdm]

Thank you for this PR! I think it's really promising that the changes required to use a different TLS engine under the hood are relatively self-contained, and it bodes well for the future. That being said, I see some drawbacks to merging this PR right now - the core team is actively focused on several high priority projects right now, and deciding on the future of the SSL stack in Servo takes time and energy that are in short supply. I think we conceptually like the idea of moving away from OpenSSL to RusTLS, but we're not comfortable making that switch without due diligence.

While choosing to merge this PR does not require making a commitment to switch to RusTLS, it does require maintaining this code across all of our existing supported platforms and dealing with any problems that arise when we update our Rust compiler toolchain. I would prefer not to do that until we're ready to consider integrating RusTLS into Servo, given the lack of time and resources we face in our existing work.

I'm going to go ahead and close this PR, but I want to emphasize that it's really interesting! The network stack of Servo is generally some of the least worked-on code in the project, and when we next focus on improving it perhaps we can revisit this topic.