tls: consider switching default to rustls

[carllerche]

rustls is an implementation of TLS in Rust, backed by ring. It supports many of the newest features provided by TLS, but does not support old functionality that ~10% of websites require.

The question is, should tokio-tls switch to rustls or should tokio-tls stick to native-tls.

This issue is to track the discussion (instead of ad-hoc convos in gitter). I will attempt to maintain a summary of the pros / cons discussed in this description.

/cc @sfackler @ctz

[Ralith]

The main argument against seeking to support obsolete functionality is that it presents a false sense of security.

Another concern with rustls is gracefully interoperating with OS certificate stores, which native-tls already does by default. This is probably achievable with some glue code, that could live in rustls or a helper crate:

• On Linux, openssl-probe can be used to find a certificate bundle and/or directory
• On Windows, various APIs can be used to access the certificate store's contents, or defer verification directly to the OS: https://stackoverflow.com/questions/9507184/can-openssl-on-windows-use-the-system-certificate-store

[djc]

Cribbing some notes from a conversation that happened in the tokio-rs/dev Gitter channel (May 13th, with some follow-up from the tokio-rustls maintainer on May 21st):

• Possibility of supporting both native-tls and rustls through tls-api

• 535 was closed, but would probably be much more feasible with rustls

• tokio-rustls is pretty small
• Currently tokio-tls (native-tls based) lives in the tokio repo, while tokio-rustls does not
• linkerd uses rustls, tower-http-tls will use it too
• The name "tokio-tls" and the fact that it's in the repo makes it look like it's the preferred option
• quinn (potentially tokio-quic) depends on rustls, TLS is pluggable but no other impls so far
• "it seems 'right' to use the OS tls lib"
• Dynamic linking means TLS is kept up to date with the TLS
• Can't use native-tls with any more advanced TLS features (like ALPN)
• Maybe code size is a disadvantage to including rustls?
• Some people dislike old ring versions getting yanked
• rustls has not been audited
• rustls does not support TLS v1.0 and v1.1 and AES-CBC cipher suites
• tokio-tls should probably be called tokio-native-tls
• Maybe write some documentation to clarify the trade-offs
• Should still have good defaults
• "in popular websites, there are still a large number of websites that cannot be accessed using rustls", for example swift.org (only RSA key exchange -> unsupported in rustls)

Also, rustls is substantially faster.

My takeaway is that we can't reason ourselves out of the trade-offs here, and the best way forward might be to rename tokio-tls to tokio-native-tls to be more obvious about what it actually is and document the trade-offs so users can decide for themselves.

cc @ctz

[DoumanAsh]

I think ideally people would want to have single crate that could be switched to different backend using features.

[carllerche]

@DoumanAsh we could do that... the main question would be whether or not we could expose modern TLS functionality that only rustls supports.

[emk]

Thank you to everyone who maintains tokio and its SSL support!

I maintain https://github.com/emk/rust-musl-builder, which is one of the semi-popular ways to build statically-linked Rust applications on Linux.

The OpenSSL C library is a source of constant misery: It doesn't follow semver, it breaks compatibility in subtle ways between 1.1.0 and 1.1.1 releases, it requires a bunch of extra work to link statically, and so on.

I would absolutely love to see a pure-Rust option on Linux/Unix systems, as long as it has something like openssl-probe to find the OS cert store, and it can a reasonable fraction of real-world web servers.

Ideally all this would go through a layer similar to native-tls, so that we could still use OS SSL on Mac and Linux.

[djc]

Note that @ctz recently started sketching out rustls-native-certs.

[djc]

@carllerche any thoughts on which direction you want to go in?

[ctz]

Another concern with rustls is gracefully interoperating with OS certificate stores, which native-tls already does by default. This is probably achievable with some glue code, that could live in rustls or a helper crate

Note that I recently released the first release of a crate which fulfils this goal.

[carllerche]

@ctz awesome!

@djc @ctz I think the strategy we should explore for tokio-tls is to be an "api shim" layer and have feature flags for the various implementations. So, you would do:

tokio-tls = { version = "*", features = ["rustls"] }

And just not pick a default. What does everyone think?

[stepancheg]

@DoumanAsh this is what tls-api crate is doing (Disclaimer: code quality is bad, but the idea is right, I think)

[stepancheg]

@carllerche

tokio-tls = { version = "*", features = ["rustls"] }

What does everyone think?

Specifying TLS implementation in each crate is OK, but it would be better to just have an API (tls-api crate), and implementations in separate crates (tls-api-openssl, tls-api-rustls, ...). No feature flags needed, implementations API for different TLS implementations live in different crates, all libraries which require TLS are implementation neutral, and final apps decide which implementation to use with a dependency on implementation crate and a reference to a type in the main function.

[dependencies]
tls_api_openssl = "*"

fn my_app<C: tls_api::TlcConnector>() { ... }

fn main() {
  run_my_app::<tls_api_openssl::TlsConnector>();
}

(This is what my tls-api* crates do)

[Darksonn]

tokio-tls is no longer in this repository