The OpenSSL Software Foundation today released  a completely refreshed version of the software, OpenSSL, that handles much of the encrypted communications for the Internet.

The latest version, OpenSSL 3.0, adds compliance with the Federal Information Processing Standards (FIPS), deprecates — with a plan to remove — a slew of low-level API functions that could cases security issues, and has added much more testing to the development processes. Reducing the number of low-level API functions means reducing the number of ways that developers could misuse or mistakenly use those functions, says Chris Eng, chief research officer at application security firm Veracode.

The major version upgrade "includes a number of architectural changes that will help developers reduce attack surface while still retaining the functionality they may have come to rely on," he says, adding that deprecating the low-level API functions will "discourage developers from tweaking the internals of individual cryptographic algorithms and steering them toward 'high level' APIs that are less prone to developer error."

OpenSSL is a popular encryption library that serves as the foundation of the encrypted Web, allowing sites to offer the Secure Sockets Layer (SSL) version of Web traffic, most commonly recognized by its prefix, HTTPS. While the software had done its job quietly, it came to prominence after a major flaw, dubbed Heartbleed, left about a third of websites vulnerable to attacks and could have leaked memory from affected servers. The 2014 vulnerability — affecting the OpenSSL implementation of the Transport Layer Security (TLS) — led to a massive effort to patch systems, followed by a major audit in 2015, and the discovery of additional vulnerabilities.

OpenSSL, which had only a single full-time software engineer at the time of the Heartbleed vulnerability and received only about $2,000 in donations each year, now has a deeper bench and more funding. The work consisted of three years of work by more than 350 developers, 17 alpha releases, and more than 7,500 commits, Matthew Caswell, a full-time developer and committer on the OpenSSL Project, stated in a blog post announcing the release of OpenSSL 3.0.

"The OpenSSL project is fortunate to have had a number of full-time engineers who worked towards OpenSSL 3.0, financed in a number of ways," he said. "We would like to extend thanks to all the companies that have support contracts with us; have sponsored specific features such as FIPS; the companies that provide sponsorship donations; and the organizations and individuals who donate through GitHub sponsors."

OpenSSL 3.0 also introduces the concept of providers, which determine which cryptographic algorithms are available for use. The initial library comes with five different providers as standard, which can be specified in the code or through configuration files.

Rival "Rustls"
The history of vulnerabilities that has affected OpenSSL has led to increased focus on efforts to create simpler cryptographic libraries and ones written in languages that reduce the likelihood of introducing vulnerabilities into the code. Rustls is one such effort, supported by Google and other companies.

Rustls, pronounced "russels," is a TLS implementation written in the Rust language. Rust is a memory-safe language developed by the Mozilla Foundation that has gained a number of corporate fans, including Google, Microsoft, Cloudflare, and Amazon. Rustls, written in Rust, is reportedly faster than OpenSSL, has had security audits, and will — like OpenSSL — have a FIPS implementation.

"OpenSSL is still very relevant and securing it is a big deal, and there are a bunch of good improvements in 3.0," says Josh Aas, executive director of the Internet Security Research Group (ISRG), which supports Rustls as part of its Prossimo initiative to create more secure versions of critical Internet components.

"There are a lot of difficult problems in computer science and computer security that we are not really sure how to solve," he adds. "We don't know how to eliminate whole classes of bugs, but when it comes to memory safety, we know how to solve that, so it's not about having the solution, but just having a lot of work to do."

Veracode's Eng agrees that the work on Rustls will create a more streamlined library. He also agrees that there is a lot of work to do to modify existing applications to work with the Rust-based cryptography library.

"Reducing attack surface is always good for security, and if you're certain you'll only ever need the most modern cryptography, alternative libraries might be a solid choice," he says. "However, if any of your customer base is stuck using outdated operating systems and Web browsers, you might run into scenarios that these modern libraries don't support."

In the end, Eng says, software developers and enterprises will have to determine whether the long term benefits of a memory-safe library will be worth it in the end.