BearSSL Joins Other Modern TLS Software Libraries To Make The Internet More Secure

Thomas Pornin, a Canadian security expert and author of multiple cryptographic algorithms and research papers, has begun working on a leaner, faster, and more secure software implementation of TLS protocols called “BearSSL." The software library, written in C, will be a competitor to the much more bloated and legacy code-encumbered OpenSSL. It will even compete with the more stripped down LibreSSL and Google’s own BoringSSL libraries.

Post-Heartbleed OpenSSL Competitors

The vast majority of software that needs to use TLS encryption uses the almost two-decade-old OpenSSL software library. Over time, buggy code has accumulated in the library. This only really started becoming apparent when the Heartbleed bug appeared in 2014, and it came to the forefront when more people started dissecting, stripping down, and creating their own competing OpenSSL alternatives.

LibreSSL is one of the OpenSSL competitors created after the Heartbleed discovery. It's a fork of OpenSSL that the group behind the OpenBSD operating system maintains. Almost immediately, the group stripped 90,000 lines of code from OpenSSL. They have cleaned their SSL library further since then while adding new modern features.

Last year, Google announced BoringSSL, another OpenSSL fork. The company aimed to clean-up OpenSSL and then used it as a special version for Google projects only. Android 6.0 (and newer) already uses BoringSSL, as well as Chrome, which began several versions ago.

Brian Smith, a security expert and a former Mozilla employee, has also started work on his own “Ring” crypto library project, which uses BoringSSL algorithms but completely new code. The new library aims to use mostly Rust, the memory- and thread-safe programming language sponsored by Mozilla that it also uses to write faster and more secure Firefox components. Ring will also use Assembly where Rust can’t be used safely, or when even higher performance is required to avoid timing attacks.

BearSSL

While the crypto libraries mentioned above are all some variant of a much-improved OpenSSL, they appear to share some components with OpenSSL. Ring would fit this definition the least, considering it’s all new code and it likely uses BoringSSL algorithms that have already been rewritten by the Google security team.

BearSSL will be completely written in C for performance reasons. This could be a detriment in the long term if more people contribute to it that don’t have the same grasp of the C language as the original author does. For now, Pornin should ensure that he only uses safe C language components. One of the ways he’s doing is that by striving to offer as much code documentation as possible, both for the architecture of the library and the API usage.

Because it’s written from scratch and designed for high-performance, BearSSL can fit in only 20 KB of compiled code and consume only 25 KB of RAM. The lightweight design makes the library highly suitable not just for desktop and mobile operating systems, but also for the leaner IoT platforms that are in dire need of good security.

Thomas Pornin also aims to make the library highly portable and feature-rich so that as many developers and platforms as possible can use it.

Features

BearSSL already supports TLS 1.0, 1.1, and 1.2 in version 0.1 of the library (still in alpha stage). Other libraries have already deprecated SSL 3.0, so BearSSL won’t support it, either.

It will also support RSA, ECDH, and ECDHE, too, while DHE won’t be because it doesn't offer advantages over ECDHE and developers often use it wrong, according to Pornin. BearSSL will also support AES/GCM, AES/CBC, and 3DES/CBC ciphers, as well as RSA and ECDSA cryptographic signatures and SHA-1 and SHA2 hash functions.

All algorithm implementations will be “constant-time” by default to avoid timing attacks. Other features, such as a secure renegotiation, static linking model, no dynamic allocation, and a state-machine API are also included, among others.

More modern features are also planned for implementation, such as the upcoming TLS 1.3 protocol, the Curve25519 elliptic curve, the ChaCha20-Poly1305 encryption mode, as well as optimizations for the x86 and ARM architectures.

It remains to be seen if any of the newer TLS software libraries will make a significant dent in the popularity of OpenSSL, which is currently getting funding from the Linux Foundation so that it can receive its own cleanup and improvements.

Newer libraries have the advantage of not having much legacy code in them, if any at all, or the advantage of being written from scratch in a much safer way than previous libraries were. Adopting them could mean fewer critical vulnerabilities in the software that’s supposed to ensure integrity and confidentiality of internet traffic.

Updated, 11/07/2016, 9:50am PT: The post was updated to specify that Brian Smith is now a former Mozilla employee, as well as to rectify a few other errors.