Rustls turned ten years old this month. The memory-safe TLS library, written in Rust, marked the anniversary with a retrospective covering its evolution from a side project into one of the most performant and widely adopted TLS implementations available. The numbers tell the story: on x86_64 hardware, Rustls 0.23.37 handles 2,357 full handshakes per second per core. OpenSSL 3.6.1 manages 1,713. BoringSSL gets 1,302.
The project started in May 2016 and released version 0.1.0 the same year. Within months it achieved broad site interoperability, which is the minimum bar for a TLS library to be taken seriously. What happened over the next decade is more interesting than the initial launch. Rustls went from a grassroots effort by independent contributors into a sustainably funded open source project with dedicated maintainers, third-party security audits, and a feature set that now includes post-quantum cryptography, FIPS certification, and Encrypted ClientHello.
How Funding Changed the Project
The early years were driven by individual contributors, notably Brian Smith and Dirkjan Ochtman. The turning point was external funding. The Internet Security Research Group's Prossimo initiative provided targeted support, and Amazon Web Services backed development directly. CNCF commissioned third-party audits from Cure53, which gave potential adopters confidence that the code had been reviewed by independent security researchers.
This funding model matters because it solved the problem that kills most open source infrastructure projects. The maintainers could work on Rustls full time. They could invest in architecture refactoring, robustness improvements, and compliance features that do not generate excitement on social media but are essential for production use. The result is a library that has been integrated into major web infrastructure and toolchains without the reliability issues that come from volunteer-maintained critical code.
The 0.23 Stability Record
Rustls developers on Reddit and Hacker News frequently point to the 0.23 release line as evidence of disciplined API management. The release sustained dozens of non-breaking updates without forcing downstream projects to rewrite their integration code. This kind of stability is rare in the Rust ecosystem, where major version bumps are common and breaking changes are often treated as a necessary cost of progress.
The practical effect is that teams running Rustls in production have not had to chase version upgrades. They can adopt security patches and performance improvements without worrying that a minor release will break their build. For a TLS library, where a regression can mean dropped connections or exposed data, this predictability is more valuable than any new feature.
Where the Performance Comes From
The benchmark numbers are not just about raw speed. They reflect architectural decisions that favor modern hardware. Rustls avoids the C-specific patterns that make OpenSSL and BoringSSL vulnerable to memory safety bugs. It uses Rust's ownership model to manage buffer lifetimes, which means fewer copies and fewer places where a buffer overflow can occur.
For full handshakes, Rustls outperforms OpenSSL by 1.38x and BoringSSL by 1.82x. Resumed handshakes show an even larger gap: 7,249 per second versus 5,687 for BoringSSL and 3,780 for OpenSSL. Throughput is competitive across the board, with Rustls achieving 7,333 megabytes received per second per core. BoringSSL edges ahead on send throughput at 7,565 megabytes per second, but the margin is only 2 percent.
These numbers matter for high-throughput servers handling thousands of concurrent TLS connections. The difference between 1,713 and 2,357 full handshakes per second translates directly to how many new connections a server can establish before it needs to scale horizontally.
What 0.24 Changes
The upcoming 0.24 release makes several architectural changes that build on the stable 0.23 foundation. The most significant is external buffering through a new TlsInputBuffer trait. Instead of routing all data 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.
For applications handling full-duplex traffic, the release introduces a split mode feature that the community first requested 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 can operate independently on different threads using a low-contention internal back-channel. The practical result is that full-duplex applications can effectively double their throughput.
Asynchronous programming gets a rework as well. New session types model handshake states sequentially, allowing handshakes to run in blocking, async, or completion-based styles. This means the same Rustls code can work across different async runtimes without requiring separate integration layers.
Finally, cryptography providers are decoupled into separate crates. Instead of using build features to select between rustls-aws-lc-rs and rustls-ring, each becomes its own dependency. This removes the build-feature unification panics that have plagued projects trying to use multiple crypto backends and allows global providers to be configured externally.
The Path to 1.0
After 0.24 stabilizes, the maintainers plan to transition toward a stable 1.0 API designed for long-term maintenance. This is the natural next step for a library that has spent a decade proving itself in production. The 0.x series has been the proving ground for API design, performance optimization, and security hardening. A 1.0 release would signal that the API is stable enough to guarantee backward compatibility for the foreseeable future.
For teams evaluating TLS libraries, the calculus has changed significantly since 2016. Rustls is now faster than OpenSSL, memory-safe by construction, backed by independent security audits, and backed by a funding model that ensures long-term maintenance. The performance benchmarks are not theoretical. They are measured against the libraries that currently power most of the internet's encrypted traffic.
The ten-year retrospective is not just a celebration. It is evidence that memory-safe systems programming is practical, that sustainable open source funding works, and that a TLS library written in Rust can outperform the C implementations it was designed to replace.