#tls

tls-api-openssl

TLS API implementation over openssl crate

23 releases

✓ Uses Rust 2018 edition

0.4.0 May 17, 2020
0.3.2 Jan 3, 2020
0.2.1 Jan 1, 2020
0.2.0 May 26, 2019
0.1.8 Jun 17, 2017

#12 in #tls

Download history 64/week @ 2020-03-14 257/week @ 2020-03-21 255/week @ 2020-03-28 130/week @ 2020-04-04 191/week @ 2020-04-11 226/week @ 2020-04-18 222/week @ 2020-04-25 159/week @ 2020-05-02 459/week @ 2020-05-09 429/week @ 2020-05-16 76/week @ 2020-05-23 132/week @ 2020-05-30 102/week @ 2020-06-06 89/week @ 2020-06-13 191/week @ 2020-06-20 256/week @ 2020-06-27

921 downloads per month
Used in 2 crates

MIT/Apache

26KB
650 lines

GitHub Workflow Status License crates.io

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-stub — stub API implementation which returns an error on any operation

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.

Or you simply want to have an option to avoid building TLS library.

Dependencies

~3MB
~57K SLoC