Rustls, the presumably memory-safe Transport Layer Security (TLS) library written in Rust, celebrated its tenth anniversary with a retrospective detailing its evolution, community growth, and future roadmap. Initiated in May 2016, the project progressed rapidly to achieve broad site interoperability and released version 0.1.0 later that year. Over the subsequent decade, external contributions and targeted funding, notably through the Internet Security Research Group’s (ISRG) Prossimo initiative, Amazon Web Services (AWS), and CNCF-backed third-party audits by Cure53, helped accelerate development, introduce security audits, and incorporate modern features such as post-quantum cryptography, FIPS certification, and Encrypted ClientHello.

The development process matured significantly, shifting from a grassroots effort driven by independent contributors like Brian Smith and Dirkjan Ochtman into a sustainably funded open-source project supported by dedicated maintainers. This financial backing enabled full-time work on robustness, architecture refactoring, and compliance features.

The project’s recent trajectory has been anchored by the 0.23 release line, which has remained stable with numerous non-breaking updates. Within developer communities on platforms like Reddit and Hacker News, users have acknowledged this reliability, pointing to the consistency of the 0.23 cycle—which sustained dozens of non-breaking iterations—as evidence of disciplined API management. Adopters frequently emphasise the practical benefits of its integration into broader toolchains and web infrastructure.

In performance benchmarks comparing Rustls (version 0.23.37) against OpenSSL (version 3.6.1) and BoringSSL on x86_64 architectures, Rustls delivers 2,357 full handshakes per second per core, outperforming OpenSSL at 1,713 (1.38x slower) and BoringSSL at 1,302 (1.82x slower). For resumed handshakes, Rustls leads with 7,249 per second per core, compared to BoringSSL's 5,687 (1.28x slower) and OpenSSL's 3,780 (1.92x slower). In terms of throughput, Rustls achieves 7,333 megabytes received per second per core—surpassing OpenSSL at 6,238 and BoringSSL at 6,218 (both 1.18x slower). For data sent, BoringSSL marginally leads at 7,565 megabytes per second per core (1.02x faster than Rustls), while Rustls processes 7,421 megabytes per second per core, beating OpenSSL's 5,844 (1.27x slower).

Building upon this stable foundation, the upcoming 0.24 release promises significant architectural changes aimed at performance, flexibility, and ecosystem integration. A primary modification is the shift to external buffering via the new TlsInputBuffer trait: Rather than routing all data directly through standard I/O traits, input arrives through this mechanism, and output appends to user-provided vectors. This enables in-place decryption and eliminates redundant memory copies. Additionally, 0.24 addresses asynchronous programming via session types that model handshake states sequentially, allowing handshakes to run in blocking, async, or completion-based styles.

To maximise performance under full-duplex workloads, the 0.24 release introduces a unique "split mode" feature first requested by the community in 2019. Previously, a single connection object handled both sending and receiving. In split mode, post-handshake traffic is decoupled into separate SendTraffic and ReceiveTraffic objects that implement Send. Because these objects can operate independently on different threads using a low-contention internal back-channel, applications handling full-duplex traffic can effectively double their throughput.

Furthermore, the 0.24 release decouples cryptography providers into separate crates (such as rustls-aws-lc-rs and rustls-ring), removing build-feature unification panics and allowing global providers to be configured externally.

Following the stabilisation of the 0.24 release, maintainers plan to transition toward a stable 1.0 API designed for long-term maintenance.