Rustls Looks to Provide a Memory-Safe Replacement for OpenSSL

The Internet Security Research Group (ISRG), with financial support from Google, has teamed up with the Rustls (pronounced “russels”) transport layer security (TLS) project to implement a number of changes to the open source project in hopes of offering a replacement for OpenSSL as part of its Memory Safety Initiative.

OpenSSL, as with many systems-level applications, is written primarily in C, and a big part of the issue at hand is that languages such as C and C++ are not memory safe, which can lead to security vulnerabilities. In 2019, for example, Microsoft disclosed that nearly 70% of all security vulnerabilities in their products were a result of memory safety issues. In the case of OpenSSL, there have been many vulnerabilities due to memory safety issues; the Heartbleed bug is just one such infamous vulnerability. Rustls, by contrast, is written primarily in Rust, a memory-safe language, and ISRG’s efforts to improve Rustls aim to prepare the library for wider adoption.

“What’s new here is that we now have a language that gives us a memory-safe option at what I would call a systems level,” explained ISRG executive director Josh Aas. “Now we’re getting a chance to take a look at some of the lower-level systems code and think, ‘Alright, we can do this better. Now we have an option.’ Memory safe languages are typically significantly slower than C, so it used to be that if you even could write something in a memory safe language, you would often have to make a choice between safety and performance. With Rust, we don’t have to make that trade-off anymore. We can have safety and performance.”

Rust has been a popular choice of late for providing a memory-safe alternative to C, with the language finding itself being selected for numerous systems-level rewrites. In recent times, Google has announced the adoption of Rust in Android, the language has tip-toed into being used in the Linux Kernel, and Microsoft has explored its use for rewriting parts of Windows. On the point of performance, specifically, recent benchmarks comparing Rustls with OpenSSL actually found that Rustls outperformed its counterpart with better connection speeds and a smaller memory footprint.

The ISRG’s Memory Safety Initiative aims to identify code that is critical to the internet but written in languages that are not memory safe, and then to transition that code to memory-safe languages to get rid of entire classes of security vulnerabilities. Aas explained that Rust is an ideal candidate for replacing C not only because of its performance, but also because the language lacks a runtime, unlike many other memory-safe languages, and allows you to rewrite programs written in C incrementally. Unfortunately, Aas said, OpenSSL won’t be able to be rewritten, so instead they are working to prepare Rustls to replace it entirely. Already, ISRG has replaced OpenSSL with Rustls in the Apache HTTP Server and Curl, and now the organization is working to further that movement.

“Another big issue is that the API that’s used with OpenSSL is very complicated, so people using open SSL tend to make mistakes in their implementation because of how confusing and complicated the OpenSSL API is,” said Aas. “Rustls has a much safer and easier-to-understand API, so we’re really getting to two things out of this transition here. We’re getting the memory safety that comes with Rustls and we’re getting the safer API.”

Specifically, ISRG and Google are contracting Rustls contributor Dirkjan Ochtman to make several improvements to the project, such as improving “the C API so that Rustls can even more easily be integrated into existing C-based applications” and enforcing “a no-panic policy to eliminate the potential for undefined behavior when Rustls is used across the C language boundary.” The ISRG’s work with replacing OpenSSL in the Apache HTTP Server took a similar path, with Google-provided funding being used to hire an httpd committer to perform the necessary updates.

“The C programming language is 50 years old, which is crazy to think about, so it’s time we start moving past it. There’s 50 years worth of C code, though, that we have to interoperate with throughout that process, otherwise, we’re never going to get there. So working incrementally is going to be key,” said Dan Lorenc, a security software engineer at Google. “Working with existing maintainers, wherever we can, is by far the most effective and best way to do it. Maintainers of open source projects like this are underpaid, under-supported from the start, and so huge companies that are relying on them just making demands isn’t really a good strategy. We like to support them to make these improvements wherever we can, rather than just asking for free work or rather than rewriting things ourselves. It’s way better to work with the community where we can.”

Aas said that they would like to see Rustls continue to replace OpenSSL and other unsafe TLS libraries, and that with each integration they learn something that makes the next one easier.

“Anywhere you can use OpenSSL, which is everywhere these days, from cars to cloud services to home web servers and appliances, you should be able to use Rustls over time,” said Aas, “so it’s a big deal that will affect a lot of people.”