Rust TLS API and implementations

Several crates:

tls-api — TLS API without any implementation and without dependencies
tls-api-native-tls — implementation of TLS API over native-tls crate
tls-api-openssl — implementation of TLS API over openssl crate
tls-api-rustls — implementation of TLS API over rustls crate
tls-api-schannel — missing implementation of TLS API over schannel crate
tls-api-security-framework — missing implementation of TLS API over security framework crate
tls-api-native-tls — stub API implementation which returns an error on any operation
tokio-tls-api — fork of tokio-tls which uses tls-api instead of native-tls

The problem

If you develop a library, you do not know which TLS library your user would like to use, and if they need any TLS library at all.

Because of that some libraries simply depend on specific TLS implementations, while others provide "features" to turn on specific dependencies.

It makes development for both library authors and library users inconvenient. Both authors and users need to configure "features" in Cargo.toml and #[cfg] in code. For example, your library need to support three options: use openssl, use native-tls, and no TLS at all. So you need to compile your library three times to check it can be compiled properly with all three options.

The solution

Library authors simply write the code with tls-api library. Since tls-api is lightweight, library authors can simply write code using it, and have no configuration options.

Library users simply call that library with different implementations of connectors and acceptors.

Example

api-test contains tests implementation independent of any library. And identical tests which use:

Status

	openssl	native-tls	rustls
Can fetch google.com:443	Yes	Yes	Yes
Server works	Yes	Yes	No
ALPN	Yes	No	No

Why not simply use native-tls

native-tls uses security-framework on OSX, and security-framework does not support ALPN.