Review Transport Layer Security solutions

[ashfordneil]

There are lots of options available, we should look into answering the following questions for each of the options to a newcomer (or myself, because I personally want to know what to use)

• is this library secure + able to be trusted
• does this library require dynamic linking against system wide libraries + how do I do that
• how do I write a docker file to build my project that uses this library
• is this library usable with {Async, no_std, etc}
• how featureful is this library (does it only do a subset of what TLS allows)
• how well designed is the api of this library (am I able to accidentally write insecure code easily using this api)

[jsgf]

We have strong requirements of our TLS libraries, mostly to do with using all corners of client cert validation. In general, the cross platform libraries seem to be insufficiently powerful - we end up needing the full OpenSSL (or equiv) API.

A platform agnostic API would be nice, but its secondary to having the right functionality even if it needs multiple implementations/conditional code.

[therealprof]

@jsgf I found mbedTLS to be catching up nicely.

[KizzyCode]

We should also consider to wrap existing OS-native APIs like it's done in native-tls. There are two main reasons for this:

• Better integration: e.g. under macOS most foreign TLS libraries do not work correctly because they do not handle the Keychain (macOS' trust store) properly – sometimes they do not find a valid root certificate storage, sometimes they ignore user settings like custom trust settings, system-wide enforced OCSP validation etc.
• Better testing: OS-TLS-stacks are heavily tested – and even there, mistakes happen. Of course we have the "Rust-advantage" if we write a native implementation, but it's still going to be pretty tough to achieve a similar level of security.

The first point might be solvable, but it would result in a whole bunch of platform-dependent code, probably even calling unstable APIs.
But I think the second point is the real dealbreaker here because it's a matter of trust. OpenSSL is well established and so are mbedTLS, SChannel and the Security Framework – our new Rust library is not (yet). And if there isn't an important name like Mozilla or a well known developer behind it, this may take a very very long time.

[ctz]

It's not totally the same as this issue, but I'd really like to see a well-adopted set of traits abstracting over TLS usage between applications and libraries. This means libraries implementing higher level protocols (eg, HTTP/1, HTTP/2, WS, etc.) can interact with TLS via these traits, and leave the concrete choice to higher in the application stack.

There are already things in this direction: tls-api notably -- but it would benefit from people power to gain maturity.

But sadly there's a huge number of protocol-level crates use native-tls directly, and native-tls is the defacto choice for TLS in the ecosystem.

That's unfortunate, in my opinion. Particularly if you compare the golang and Rust ecosystems: golang comes out-of-the-box with a memory-safe, enthusiastically-maintained and well-regarded TLS stack whose use is pervasive. Rust comes with -- well nothing -- but most commonly people use libraries with a long history and uncertain future of catastrophic memory safety bugs :(

I think the first step in making this situation better is to make it easier for people to choose alternatives.

(Disclosure: I'm the author of rustls)

[djc]

I very much agree with @ctz. I think people use Rust in part because they believe it will be more secure in security-sensitive contexts, and the best we can do is make it easy to swap out the old and mature but often vulnerable libraries out for pure Rust implementations, so that those can mature.