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.
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.
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.
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.
The expiration date of the OpenSSL release signing key with fingerprint
BA5473A2B0587B07FB27CF2D216094DFD0CB81EF has been extended from 08 Apr 2026 to 14 Jun 2026.
Only the key expiration date has changed. The signing key itself remains the same.
