tokio-rustls

tokio-rustls bridges the Rustls pure-Rust TLS implementation with Tokio’s async I/O traits, giving Rust network code an AsyncRead/AsyncWrite TLS stream that composes with the rest of the Tokio ecosystem. It wraps a rustls::ClientConnection or rustls::ServerConnection in a TlsStream type, driving the TLS handshake and record layer asynchronously so callers can .await a connect()/accept() call instead of managing the handshake state machine by hand.

Because it delegates all cryptographic and protocol logic to Rustls, tokio-rustls stays a thin, focused adapter layer: its own source is under 1,500 lines split across a client module, a server module, and a small shared handshake driver. It underpins TLS support in a large share of the async Rust ecosystem, including HTTP clients/servers, proxies, and database drivers that need TLS without depending on OpenSSL.

What You Get

• TlsConnector and TlsAcceptor types that wrap a Rustls ClientConfig/ServerConfig for building TLS client and server streams
• A TlsStream<T> wrapper implementing AsyncRead/AsyncWrite over any inner async transport, most commonly a Tokio TcpStream
• Feature flags to select the crypto backend (aws_lc_rs or ring), enable TLS 1.2 fallback, early data, or zlib/brotli certificate compression
• Early-data (0-RTT) support for TLS 1.3 clients that need to avoid a full round trip on reconnection

Common Use Cases

• Adding TLS termination or client TLS to a Tokio-based network service without linking against OpenSSL
• Implementing HTTPS support in async HTTP clients/servers and reverse proxies written on top of Tokio
• Securing database or RPC client connections that need TLS but want a pure-Rust dependency chain
• Building custom async network protocols that need to layer TLS transparently under existing AsyncRead/AsyncWrite code

Under The Hood

Architecture - The crate is a thin async adapter: src/client.rs and src/server.rs each define a stream type wrapping a Rustls ClientConnection/ServerConnection, implementing poll_read/poll_write by driving the Rustls state machine and the underlying transport’s poll methods in lockstep; src/common/handshake.rs implements the shared connect/accept handshake future that both client and server paths reuse, and src/common/mod.rs holds the shared TlsStream buffering logic. Tech Stack - Rust 2021 edition (MSRV 1.71), with rustls as the sole required dependency (default features disabled, std feature enabled) and tokio for the async I/O traits; feature flags let consumers pick between aws_lc_rs and ring as the underlying crypto provider, and optionally enable TLS 1.2, 0-RTT early data, or certificate compression. Code Quality - tests/test.rs, tests/early-data.rs, and tests/badssl.rs (real-world TLS server) exercise handshake correctness, early data, and interop against live endpoints; the crate also runs cargo_check_external_types in CI to police its public API surface and prevent accidental leakage of internal Rustls types. Its own source is small (~1,250 lines) since it delegates all TLS protocol and cryptographic logic to Rustls. API Design - The public API mirrors std/Tokio idioms closely: TlsConnector::connect and TlsAcceptor::accept return futures that resolve to a TlsStream, so integrating it into existing async networking code is typically a one-line wrap around an existing TcpStream, with feature flags handling crypto-backend selection at compile time rather than runtime configuration.