Josh Aas
Apr 9, 2026
Overview
Offering top tier performance is a primary goal for the Rustls project. As such, the project has developed benchmarks representing some of the most performance critical functions and monitors them closely.
The Rustls project periodically publishes test results that compare Rustls performance to other popular TLS libraries, OpenSSL and BoringSSL.
The previously published test results are from July of 2025. The Rustls project is planning to start publishing performance reports more frequently going forward.
Here's how library versions have changed since the previous results:
- Rustls: 0.23.31 (aws-lc-rs 1.13.1) -> 0.23.37 (aws-lc-rs 1.16.0)
- OpenSSL: 3.5.1 -> 3.6.1
- BoringSSL: July 2024 -> March 2026 snapshot
The testing discussed here was done in March of 2026.
Results
Analysis
| Library | First Place | Second Place | Third Place |
|---|---|---|---|
| Rustls | 14 | 2 | 0 |
| BoringSSL | 2 | 10 | 4 |
| OpenSSL | 0 | 4 | 12 |
Since the last tests in July of 2025, neither BoringSSL or OpenSSL significantly improved or regressed in any test. Rustls got a bit faster in a few tests, likely because of improvements to the underlying cryptography via updates to aws-lc-rs.
The results on the whole are roughly what we'd expect. OpenSSL is known to have serious performance issues, BoringSSL avoids most of those, and Rustls takes performance a step further.
Looking Forward
Rustls 0.24 will be released this year with a large number of changes focused on building a strong foundation for a 1.0 release. In particular, Rustls is making some changes to its APIs that will serve users better for the long term.
One performance-related change we are pursuing is "split mode". This is where — after the TLS handshake — a connection can be split into sender and receiver objects. The sender can send TLS-protected data, while the receiver can receive it. Historically this has been challenging because in TLS, a receiver may need to occasionally write (e.g. to send an alert). To address this challenge the split objects have an internal relationship to ensure that (for example) if the receiver object needs to send a message, that can happen in a transparent way. This is a very infrequent occurrence, so doesn't cause contention in normal use.
The intention is that those objects can be used on separate threads, which allows total throughput for a connection to be roughly doubled. The above measurements are per-core, but we're not aware of other TLS libraries that allow the use of one connection from two threads like this. Therefore, the send and receive measurements of Rustls could be added together. We'll confirm that is practically possible in a future performance report.
That is all caveated on applications that can be structured to benefit from full-duplex use of a single connection. Luckily, tokio already has this pattern as a first-class concept. We hope the Rustls split-mode feature will contribute to cementing Rust as a great choice for mega-fast and safer network services.
Large releases like this can be a mixed bag for performance, but the team monitors regressions closely and so at a minimum, no significant regressions are expected. For some of the closely contested results it's possible that Rustls 0.24 could pick up or lose a place. If that happens, we'll prioritize improvements that get Rustls back to the prior position.