rustls 0.24 introduces external buffering, async-friendly usage, split mode, and modular cryptography providers

rustls 0.24 reworks its I/O model to address long-standing inefficiencies. By moving buffering outside the library, it avoids extra copies and awkward error handling tied to std::io traits. The new TlsInputBuffer trait lets users provide their own buffers, with plaintext returned as a borrow into the input buffer. This change also unlocks no-std support, a requirement for embedded or resource-constrained environments. The trade-off is that porting existing code requires adapting to the new trait-based I/O, though VecInput offers a compatibility path for io::Read users.

The release introduces a session-type system to model the TLS handshake process, replacing the previous Acceptor API. Servers and clients now progress through distinct states (e.g., NeedsInput → Accepted → VerifyClientIdentity → Complete), each of which can be driven synchronously, asynchronously, or via completion-based callbacks. This design avoids waiting for Rust language features like async dyn traits, but it may feel unfamiliar to developers accustomed to monolithic connection objects. The approach allows future handshake steps to be added without breaking changes, though it shifts complexity to the caller for state management.

Split mode is the most novel feature in 0.24, separating post-handshake sending and receiving into SendTraffic and ReceiveTraffic objects. Both are Send, enabling full-duplex workloads to run on separate threads with minimal contention. This addresses a 2019 request and is described as unique among TLS libraries, but it requires applications to manage two objects instead of one. The internal back-channel between them is low-contention, but the performance gains may be limited to workloads that can fully utilize parallel sending and receiving.

Cryptography providers are now modular crates, such as rustls-aws-lc-rs and rustls-ring, rather than built-in features. This removes feature-unification panics and allows providers to be selected globally at runtime, simplifying dependency management. However, it also means users must explicitly choose and include a provider crate, adding a small setup step. The change reflects a broader trend toward modularity in security libraries, but it may complicate builds for projects that previously relied on default features.