Why we’re so excited about OpenSSL 4.0

Every release of the OpenSSL Library is an important milestone for practical cryptography. But last week we got a major release: 4.0. Major releases may include changes to the library’s interface. Since it’s been over 5 years since 3.0, the last major release, here are some things that might impact developers:

• Before 3.0, the ENGINE API allowed applications to add cryptographic algorithms. Since 3.0 introduced a more flexible solution, the provider mechanism, we no longer need ENGINE code. So it was removed along with a number of support functions in 4.0.
• Secure Sockets Layer version 3.0 (SSLv3) has been deprecated for over a decade and has also been removed. Don’t worry! Newer versions of SSL, the Transport Layer Security (TLS) protocol, remain at the core of OpenSSL.
• We also simplified how OpenSSL recovers memory when the application ends and set the table for future work optimizing memory usage.

None of these seem as exciting as, say, a new post-quantum cryptography algorithm. By nature, interface changes tend to be a minor annoyance to maintainers of downstream projects. However, removing thousands of lines of code reduces the size of the OpenSSL Library and smooths the road for future development. It also eliminates some potential vulnerabilities.

For instance, a recent vulnerability report revealed a small bug in a sanity check. Since the offending code had already been removed during the development of 4.0, nothing needed to be done for the current version. Less code means a smaller potential attack surface for people probing for vulnerabilities in the library.

That’s not all . . .

OpenSSL 4.0 doesn’t just remove code, however. When developers upgrade to this release, they will get the code to enable Encrypted Client Hello (ECH). This TLS extension, described in RFC 9848, encrypts the first message from a client to a server, known as the ClientHello. Servers that enable ECH will be able to prevent attackers from learning the identity of the host the client is connecting too. That is, to quote the RFC, “perhaps the most sensitive information left unencrypted in TLS 1.3.”

We further our mission by making privacy features, such as ECH, available to everyone via the open source OpenSSL Library. Because it is widely used, new features in OpenSSL go on to improve much of the software that powers the internet. That’s particularly important for ECH because it’s more effective the more widespread it becomes.

Stephen Farrell, who implemented ECH as a part of the DEfO project, spoke about the process at the OpenSSL Conference. He explained how OpenSSL Foundation staff got ECH into the OpenSSL Library:

We had this working, but not reviewed, code and we wanted to give it to OpenSSL and they would like to get it. But it's a humongous chunk of code. So we created a PR and the OpenSSL maintainers, Matt and Tomáš, who have been really helpful, had a look at that and went “Oh what am I supposed to do with 15,000 lines of code?” 

Typically the process has been I'll create a PR that adds the next bit of code and wait and then eventually Matt and Tomáš will get some time and have a look at it and then at that point it gets processed very quickly.

Few features are as complicated to implement as ECH, but that’s representative of the usual process. OpenSSL Foundation staff work with outside contributors to make sure their code gets the reviews it needs to become part of OpenSSL. We’re grateful to our supporters who make this possible.

For more information about ECH, see this blog post.

Photo by Michal Balog on Unsplash