Blog

The OpenSSL Project is pleased to announce that OpenSSL 4.1 Alpha1 pre-release is available, which adds significant new functionality to the OpenSSL Library.

OpenSSL 4.1, which will be released in October 2026, adds the Datagram Transport Layer Security (DTLS) protocol version 1.3.

Summary

According to the DTLS 1.3 standard:

DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse.

Therefore DTLS 1.3 offers many of the same benefits of TLS 1.3 compared to the 1.2 versions of those protocols. It is faster because the protocol reduces the number of round trips during the handshake. It is also more secure because it has removed support for outdated cryptographic algorithms. DTLS also allows for the use of Post-Quantum Cryptography (PQC) algorithms which were implemented in OpenSSL 3.5.

The 2026 OpenSSL Foundation Advisory Committee nomination period has started! The Foundation is looking for people who want to help guild the future of internet security and data privacy. Whether you are more comfortable on LinkedIn or GitHub, your advice matters.

• If you haven’t already, join a community. This is required in order to nominate someone or to vote in the election. It also opens the door to discussions about OpenSSL governance.
• During August, nominate yourself or someone else using the instructions in this guide.
• After the nominees are announced, the election will take place in the first two weeks of September.

As we previously announced, the Foundation is combining advisory committees. Representatives will have two-year terms so the cohort elected in September will serve through September 2028. For more details, see the election timeline.

Over the past week a denial-of-service (DoS) report against OpenSSL, named “HollowByte” by the Okta Red Team who reported it, has received a good deal of press attention. A number of the articles ask reasonable questions about how we assessed the report and why we handled the fix the way we did. This post sets out our analysis and the reasoning behind our decisions.

We are grateful to the Okta Red Team for the report and for the detail they put into it. The behaviour they describe is real, and we have changed OpenSSL in response to it. But the report combines two quite different things under a single headline, and separating them is the key to understanding our response.

The OpenSSL Library has adopted an AI policy. To summarize:

• Anyone who uses AI to provide a non-trivial portion of their contributions to the OpenSSL Library must:
  1. Sign an updated Contributor License Agreement (CLA) that includes the AI clauses.
  2. Declare any AI use in the commit message of each contribution. This is done via an Assisted-by trailer as explained in the policy.
• People who do not use AI, who have already signed the old CLA, do not need to sign a new CLA.

The policy goes into greater detail about what constitutes “non-trivial” contributions and how to properly declare AI use.

At ICMC26, Tim Hudson announced a change to the OpenSSL Library release schedule for future releases. Last year we committed to making long term stable (LTS) releases every two years. Following the release of 4.0, the first major release since 2018, we now commit to a major release every two years.

So the next LTS will be 4.2 in April 2027 and then we’ll have a major release, 5.0, in October 2027. That means the final 4.x release will be supported for the entire 5.x release cycle. This gives significant flexibility for projects that depend on OpenSSL to decide the appropriate moment to move to a more recent version of the library.

The final release of OpenSSL 4.0 is now live. We would like to thank all those who contributed to the OpenSSL 4.0 release, without whom the OpenSSL Library would not be possible.

Previous posts about the upcoming OpenSSL 4.0 release:

1. removing ENGINE code
2. removing deprecated functions for creating or modifying custom METHODS
3. no longer registering a function via atexit function
4. adding ECH support
5. removing SSLv3 and SSLv2 Client Hello

Summary

The ASN1_STRING structure can no longer be accessed directly. Instead, accessor functions must be used.

While these accessor functions have been available since OpenSSL 1.0.1, this change is being made now to enable future work improving X509 memory efficiency. Requiring accessor functions will allow ASN1 strings to be stored as pointers to data in read only memory instead of making duplicate copies.

Release Announcement for OpenSSL Library 3.6.2, 3.5.6, 3.4.5, 3.3.7, 3.0.20, 1.1.1zg and 1.0.2zp

The OpenSSL Project team announces the release of new versions of our open-source toolkit for SSL/TLS.

Previous posts about the upcoming OpenSSL 4.0 release:

1. removing ENGINE code
2. removing deprecated functions for creating or modifying custom METHODS
3. no longer registering a function via atexit function
4. adding ECH support

Summary

Secure Sockets Layer version 3.0 (SSLv3) was deprecated in RFC 7568. SSLv3 was disabled at build-time in OpenSSL 1.0.2h by default. As of OpenSSL 4.0, SSLv3 support has been removed altogether.

In addition, OpenSSL no longer supports the SSLv2 Client Hello.