Rustls is a modern TLS library written in Rust.

Rustls is used in production at many organizations and projects. We aim to maintain reasonable API surface stability but the API may evolve as we make changes to accommodate new features or performance improvements.

We have a roadmap for our future plans. We also have benchmarks to prevent performance regressions and to let you evaluate rustls on your target hardware.

If you'd like to help out, please see CONTRIBUTING.md.

The maintainers pronounce "rustls" as rustles (rather than rust-TLS), but we don't feel strongly about it.

The detailed list of changes in each release can be found at https://github.com/rustls/rustls/releases.

https://docs.rs/rustls/

Rustls is a TLS library that aims to provide a good level of cryptographic security, requires no configuration to achieve that security, and provides no unsafe features or obsolete cryptography by default.

Rustls implements TLS1.2 and TLS1.3 for both clients and servers. See the full list of protocol features.

While Rustls itself is platform independent, it requires the use of cryptography primitives for implementing the cryptography algorithms used in TLS. In Rustls, a crypto::CryptoProvider represents a collection of crypto primitive implementations.

By providing a custom instance of the crypto::CryptoProvider struct, you can replace all cryptography dependencies of rustls. This is a route to being portable to a wider set of architectures and environments, or compliance requirements. See the crypto::CryptoProvider documentation for more details.

Since Rustls 0.22 it has been possible to choose the provider of the cryptographic primitives that Rustls uses. This may be appealing if you have specific platform, compliance or feature requirements.

From 0.24, users must explicitly provide a crypto provider when constructing ClientConfig or ServerConfig instances. See the crypto::CryptoProvider documentation for more details.

The Rustls project currently maintains two cryptography providers:

• rustls-aws-lc-rs - a provider that uses the aws-lc-rs crate for cryptography. While this provider can be harder to build on some platforms, it provides excellent performance and a complete feature set (including post-quantum algorithms).
• rustls-ring - a provider that uses the ring crate for cryptography. This provider is easier to build on a variety of platforms, but has a more limited feature set (for example, it does not support post-quantum algorithms).

The Rustls team recommends using the rustls-aws-lc-rs crate for its complete feature set and performance. See the aws-lc-rs FAQ for more details of the platform/architecture support constraints in aws-lc-rs.

See the documentation for crypto::CryptoProvider for details on how providers are selected.

(For rustls versions prior to 0.24, both of these providers were shipped as part of the rustls crate, and Cargo features were used to select the preferred provider. The aws-lc-rs feature was enabled by default.)

The community has also started developing third-party providers for Rustls:

• boring-rustls-provider - a work-in-progress provider that uses boringssl for cryptography.
• rustls-ccm - adds AES-CCM cipher suites (TLS 1.2 and 1.3) using RustCrypto, for IoT/constrained-device protocols (IEEE 2030.5, Matter, RFC 7925).
• rustls-graviola - a provider that uses graviola for cryptography.
• rustls-mbedtls-provider - a provider that uses mbedtls for cryptography.
• rustls-openssl - a provider that uses OpenSSL for cryptography.
• rustls-rustcrypto - an experimental provider that uses the crypto primitives from RustCrypto for cryptography.
• rustls-symcrypt - a provider that uses Microsoft's SymCrypt library.
• rustls-wolfcrypt-provider - a work-in-progress provider that uses wolfCrypt for cryptography.

See the Making a custom CryptoProvider section of the documentation for more information on this topic.

Our examples directory contains demos that show how to handle I/O using the stream::Stream helper, as well as more complex asynchronous I/O using mio. If you're already using Tokio for an async runtime you may prefer to use tokio-rustls instead of interacting with rustls directly.

The mio based examples are the most complete, and discussed below. Users new to Rustls may prefer to look at the simple client/server examples before diving in to the more complex MIO examples.

The MIO client example program is named tls-client-mio.

Some sample runs:

$ cargo run --bin tls-client-mio -- --http jbp.io
HTTP/1.1 200 OK
Date: Tue, 23 Jun 2026 16:13:40 GMT
Content-Type: text/html; charset=utf-8
Connection: close
(...)

Run cargo run --bin tls-client-mio -- --help for more options.

The MIO server example program is named tls-server-mio.

Here's a sample run; we start a TLS echo server, then connect to it with openssl and tls-client-mio:

$ cargo run --bin tls-server-mio -- --certs test-ca/rsa-2048/end.fullchain --key test-ca/rsa-2048/end.key -p 8443 echo &
$ echo hello world | openssl s_client -ign_eof -quiet -connect localhost:8443
depth=2 CN = ponytown RSA CA
verify error:num=19:self signed certificate in certificate chain
hello world
^C
$ echo hello world | cargo run --bin tls-client-mio -- --cafile test-ca/rsa-2048/ca.cert --port 8443 localhost
hello world
^C

Run cargo run --bin tls-server-mio -- --help for more options.

Rustls is distributed under the following three licenses:

• Apache License version 2.0.
• MIT license.
• ISC license.

These are included as LICENSE-APACHE, LICENSE-MIT and LICENSE-ISC respectively. You may use this software under the terms of any of these licenses, at your option.

• Joe Birr-Pixton (@ctz, Project Founder - full-time funded by Prossimo)
• Dirkjan Ochtman (@djc, Co-maintainer)
• Daniel McCarney (@cpu, Co-maintainer)
• Josh Aas (@bdaehlie, Project Management)

This project adopts the Rust Code of Conduct. Please email rustls-mod@googlegroups.com to report any instance of misconduct, or if you have any comments or questions on the Code of Conduct.