Assisted-by trailer as
explained in the policy.The policy goes into greater detail about what constitutes “non-trivial” contributions and how to properly declare AI use.
]]>
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 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.
]]>The OpenSSL Project team announces the release of new versions of our open-source toolkit for SSL/TLS.
]]>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.
]]>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.
The updated public key is available at: https://keys.openpgp.org/search?q=BA5473A2B0587B07FB27CF2D216094DFD0CB81EF
]]>The OpenSSL Library now supports Encrypted Client Hello (ECH) specified in RFC 9849, which was published this month. Applications that implement this standard will be able to encrypt sensitive information that is currently transmitted in plaintext in the TLS 1.3 handshake. In particular, ECH can protect the client’s target server name from being revealed to third parties.
]]>The OPENSSL_cleanup() function is no longer registered to be called
upon the termination of the process. This means the OpenSSL Library
does not automatically free resources so the operating system reclaims
them when an application exits.
For most users, this will have no impact since the memory is freed one way or the other.
]]>For a complete list of deprecated functions removed in OpenSSL 4.0, please see the ossl-removed-api documentation. They are divided into the following pull requests:
EVP_CIPHER_meth_*) were removed in PR
#29299.EVP_MD_meth_*) were removed in PR
#29366.EVP_PKEY_meth_*) were removed in PR
#29384.EVP_PKEY_asn1_*) were removed in PR
#29405. (These
functions were deprecated in OpenSSL 3.6.)Instead of using these methods, developers are encouraged to use the provider framework.
]]>The OpenSSL Project team announces the release of new versions of our open-source toolkit for SSL/TLS.
]]>All symbols defined in openssl/engine.h have been removed from the
shared library in
OpenSSL 4.0. Applications that use the ENGINE API will fail to compile
using the default build settings. This behavior matches what happens
in previous versions when building OpenSSL with the no-engine
configuration
option
with current versions. Up-to-date applications should not include
openssl/engine.h at all.
The currently running elections are:
For details about how the election works, please consult the Foundation Election Guide.
]]>As part of this effort, we will be making some changes to our coding style guidelines and adopting clang-format using the WebKit C coding style as enforced by clang-format. We will transition to using clang-format to check pre-submissions and ensure code follows the format portions of the style guide before PRs are reviewed.
]]>| author | date | PR |
|---|---|---|
| xiaoloudongfeng | 2025-09-02 | fix length of digestinfo_sm3_der |
| Pkeane22 | 2025-09-07 | Fixed typo |
| LuiginoC | 2025-09-10 | crypto/evp/bio_ok.c:Integer Overflow in BIO_f_reliable record parser leads to Out-of-Bounds Read |
| ritesh006 | 2025-09-11 | doc: clarify SSL_SESSION_get0_hostname notes |
| jedenastka | 2025-09-11 | Fix cipher protocol ID type in docs |
| leesugil | 2025-09-14 | FIPS 186-5 auxiliary prime length check condition updated (Fixed #28526) |
| rodeka | 2025-09-16 | crypto/ml_dsa: fix public_from_private() error path to return failure |
| jonathimer | 2025-09-18 | Add Linux Foundation Health Score badge to README |
| bleeqer | 2025-09-29 | ts_conf: fix memory leak in TS_CONF_set_policies |
Here are more details on a sample of these pull requests.
]]>
The OpenSSL Corporation and the OpenSSL Foundation celebrate the success of the inaugural OpenSSL Conference, held in Prague, October 7-9. This was the first time in the history of the OpenSSL Project that the full community met in person. Developers, legal experts, and users from academics, committers, distributions, individuals, large businesses, and small businesses came together to discuss project direction, share experience, and collaborate on the future of secure digital communication.
]]>Each of the six communities (Academics, Committers, Distributions, Individuals, Large Businesses and Small Businesses) will have a representative who will serve for one year. In addition to a monthly meeting, representatives also lead discussions on the Communities platform and generally promote the OpenSSL Mission.
]]>
Lightship Security, an Applus+ Laboratories company and accredited cryptographic security test laboratory, and the OpenSSL Corporation, the co-maintainer of the OpenSSL Library, announce the submission of OpenSSL version 3.5.4 to the Cryptographic Module Validation Program (CMVP) for FIPS 140-3 validation.
This submission confirms that the code is complete and that all included algorithms have successfully passed NIST testing and independent laboratory review. The final CMVP review and certificate issuance remain as the last step in the process.
]]>The OpenSSL Project team announces the release of new versions of our open-source toolkit for SSL/TLS.
]]>| author | date | PR |
|---|---|---|
| zl523856 | 2025-08-03 | [RISC-V] Further optimization for AES-128-CBC decryption performance |
| ChillerDragon | 2025-08-04 | Improve english in endian comment |
| ritoban23 | 2025-08-13 | Fix potential null pointer dereference in pkey_dh_derive |
| vkryl | 2025-08-15 | Android: Enable 16 KB ELF alignment for arm64-v8a and x86_64 platforms |
| itot1198 | 2025-08-18 | Remove unnecessary fetch-depth in GitHub Actions workflow |
| Leonabcd123 | 2025-08-28 | Fixed typo |
zl523856 started by submitting an issue that asking about the proposed change. The pull request includes some assembly code that improves the performance of the AES-128-CBC decryption algorithm on the RISC-V architecture. It’s not the sort of code that just anyone can write. Open source projects, such as OpenSSL, can benefit from one-time contributions of expertise. In turn, anyone who uses OpenSSL or products that include the library also benefit. It’s a beautiful thing.
]]>The OpenSSL Project team announces the release of new versions of our open-source toolkit for SSL/TLS.
]]>So far in the development cycle of OpenSSL 3.6, the plurality of changes come from developers paid by either the OpenSSL Corporation or Foundation. But individual contributions continue to make up a large proportion of commits (41%) and overall changes (28%). Additionally individual committers also have done 18.5% of reviews so far.
]]>
Early Bird registration is now open for the inaugural OpenSSL Conference, taking place from October 7 to 9, 2025, in Prague, Czech Republic. Take advantage of exclusive Early Bird rates and secure your spot now!
Join the global community of cryptographers, open-source innovators, security experts, and thought leaders who shape the future of secure communications. The OpenSSL Conference promises to be a landmark event, uniting diverse perspectives from across technical, enterprise, academic, and regulatory fields.
]]>
The OpenSSL Project team announces the release of new versions of our open-source toolkit for SSL/TLS.
CVEs fixed in 3.5.1:
Specific notes on upgrading from previous versions are available in the OpenSSL Migration Guide.
]]>OpenSSL Foundation is seeking a talented and motivated Software Engineer (C Developer) to contribute to the development and maintenance of the widely-used OpenSSL open-source cryptographic library.
]]>
If you’re reading this blog post, you probably don’t need us to tell you how essential, widespread, and important the OpenSSL Library is. While our open source model means that everyone is freely able to use these tools, it also means we here at the OpenSSL Foundation don’t actually know all the great stories of how these tools are being used.
We’re looking for real stories of how the OpenSSL Library benefits your end users.
]]>
The OpenSSL Conference 2025 is extending its Call for Papers (CFP) deadline to June 22, 2025.
We understand that the best proposals often come from teams deep in the trenches of real-world security work. You now have additional time to craft and submit the talk, panel, or workshop that challenges assumptions, advances cryptographic innovation, drives and shapes the future of secure communications.
]]>
Pictured here from left to right: Štefan Kremeň (Support Manager), Peter Gutmann (cryptlib), Hana Andersen (Marcom Manager), Shayne Jones (cryptlib), Kajal Sapkota (MarCom Specialist), Kateřina Míčová (Business Admin), Daniela Kellnerová (MarCom Specialist), Norbert Pócs (Software Engineer), Tomáš Vávra (Engineering & Standards Mgr.), Anton Arapov (Operations Manager), Tim Hudson (Corporation President), Matt Caswell (Foundation President), Tomáš Mráz (Foundation Public Support and Security Manager), James Bourne (FireDaemon Technologies), Jaroslav Řezník (Red Hat), David Hook (Bouncy Castle), Billy Bob Brumley (RIT)
From May 14–16, the OpenSSL Corporation hosted a face-to-face working session in Brno, Czech Republic. The meeting was designed to bring together participants from the OpenSSL Projects and convene in an in-person meeting of the Corporation’s Business Advisory Committee (BAC). The OpenSSL Foundation was invited to join on Wednesday and Thursday in the broader conversations with the OpenSSL Projects.
This was the first time these groups gathered in person in this configuration. The sessions served as an opportunity to strengthen working relationships, align on shared priorities, and focus on strategic coordination across the ecosystem.
]]>
Dates: October 7–9, 2025 Location: Prague, Czech Republic Submission Deadline: May 31, 2025
The OpenSSL Conference 2025 is accepting proposals for talks, panels, and workshops. This inaugural event will bring together developers, researchers, security engineers, compliance professionals, and policy experts working across open-source and commercial domains. While the OpenSSL Library remains central to modern cryptography, this conference is designed to support the broader community in building secure systems and advancing internet trust.
We are looking for speakers who can share real-world experiences, technical innovations, and practical insights that contribute to the field of security and cryptographic infrastructure.
]]>Take advantage of the extended timeline to submit thoughtful nominations — and play an active role in shaping the future of the OpenSSL Library. Your voice matters!
]]>
The OpenSSL Corporation and the OpenSSL Foundation are pleased to announce the OpenSSL Conference 2025, taking place from October 7 to 9, 2025, in the historic city of Prague, Czech Republic. This premier event brings together a global community of cryptography experts, legal professionals, and open-source enthusiasts dedicated to advancing cryptography and secure communications for three days of in-depth discussions, insights, and networking.
]]>These interactive webinars offered our community the opportunity to ask questions and better understand the purpose and structure of the TACs.
]]>
The OpenSSL Corporation is pleased to announce that OpenSSL version 3.1.2 has achieved FIPS 140-3 validation, signifying its compliance with the rigorous cryptographic module security requirements set forth by the National Institute of Standards and Technology (NIST). This accomplishment marks a significant milestone in reinforcing trusted, standards-based encryption for organizations operating in regulated environments, including government agencies, healthcare institutions, and financial services.
]]>The included features can be found in the OpenSSL 3.5 Feature Go/No-Go Decision blog post.
]]>The previous LTS (OpenSSL 3.0) will continue to be fully supported until September 7, 2025 and receive security fixes until September 7, 2026. Projects that currently depend on 3.0 are strongly encouraged to switch to OpenSSL 3.5 once it has been released.
In addition, the OpenSSL Corporation and Foundation have agreed to designate an LTS every two years. That means there will be an LTS release in April of 2027, another in 2029, and so on. As always, each LTS will be supported for 5 years with the final year’s support being security patches only. For more information, please see the OpenSSL Library Roadmap.
]]>The go/no-go decisions ensure we merge well-vetted features into the main codebase for OpenSSL 3.5, complementing OpenSSL Library’s existing review process.
]]>
If you have any questions or comments regarding the OpenSSL 3.5 release contact us at feedback@openssl.org.
]]>Two of the first algorithms standardized are ML-KEM (for key agreement) and ML-DSA (for digital signatures). These algorithms are standardized by NIST in FIPS 203 and FIPS 204. These define the algorithm parameters and how to correctly perform the necessary mathematical operations, but do not define such details as data formats for public and private keys. Those details were left to other standards organisations, such as the IETF.
]]>Jon began his programming career as an intern at the US National Weather Service where he designed software to test instruments for the Automated Surface Observing System (ASOS). He continued as a programmer at the Jet Propulsion Laboratory (JPL) with the Shuttle Radar Topography Mission (SRTM) ground-data team. When that project ended, he managed data processing for the Tropospheric Emission Spectrometer (TES) mission which collected global atmospheric data from heliosynchronous orbit. Along the way he participated in open source projects such as Perl and Emacs via Usenet groups and mailing lists.
]]>The Free and Open Source Developers’ European Meeting (FOSDEM) is a volunteer-organized event to promote the widespread use of free and open source software. The conference includes 1,001 events across two days, taking place in 40 rooms on the ULB Solbosch Campus. There is no fee to participate and attend.
]]>One year ago, we celebrated the 25th anniversary of OpenSSL, marking the release of version 0.9.1c on December 23, 1998, and it seemed fitting to share this Annual Report today, on OpenSSL’s 26th birthday. So much has changed over those 26 years, but our reliance on our community of committers, contributors, and funders has not. We greatly appreciate the many contributions of many types that keep OpenSSL strong and secure and hope you enjoy reading about all that we achieved together.
]]>The “Distributions” community includes maintainers of operating systems or significant packages that integrate OpenSSL Foundation and OpenSSL Corporation projects. If you are involved in an OpenSSL distribution then we encourage you to sign up to the community and vote in the second round of the election in January.
]]>Newly Elected Members
The following candidates have been elected to serve on the Business Advisory Committee:
OpenSSL Foundation BAC Members
]]>Start Date: December 5, 2024
Deadline for Voting: December 15, 2024 11:59pm Pacific Time (US/ Canada)
Election Committee
The Election Committee is composed of the directors of the OpenSSL Foundation and the OpenSSL Corporation. This marks the first inaugural Election Committee, tasked with overseeing and managing the election processes across various communities. The committee is dedicated to ensuring that voting is conducted fairly, transparently, and in alignment with the established rules and procedures.
]]>We have heard you, and we would like to announce that:
This extension provides additional time to ensure everyone has the opportunity to nominate the individuals who can best represent the community’ s view and needs.
]]>These mirrors are accessible in locations where our original websites might be blocked.
]]>Are you looking to deepen your understanding of X.509 keys and certificates or sharpen your command-line skills?
Join us for a comprehensive webinar on X.509 certificate management led by Viktor Dukhovni, an OpenSSL Software Engineer. This session covers essential concepts and hands-on techniques using OpenSSL’s command-line tools.
]]>OpenSSL delivers the following significant new features:
Please see the CHANGES.md file in the release for a full list of changes since OpenSSL 3.3
]]>OpenSSL is hiring for a Communities Manager to join our team.
]]>A strategic leader with more than twenty years of senior-level fundraising experience, Amy has worked for prestigious educational and cultural institutions including the Wikimedia Foundation, Smithsonian Institution, The New York Public Library, and the University of North Carolina at Chapel Hill. She has been part of several record-setting fundraising campaigns, including the Smithsonian’s first-ever comprehensive campaign, which raised over $1.8 billion, and the $2 billion Carolina First Campaign, which was one of the 5 largest campaigns in US higher education at the time.
]]>Our beta releases are considered feature complete for the release, meaning that between now and the final release, only bug fixes are expected (if any). Notable features of this release are available in NEWS.md within the source tarball.
Beta releases are provided to our communities for testing and feedback purposes. If you use OpenSSL, and particularly if you intend to upgrade to OpenSSL 3.4 when it is released, we strongly encourage you to download this beta release, and test it within whatever quality control mechanisms you have, providing feedback via our GitHub issue page at http://github.com/openssl/openssl/issues, so that we can address any shortcomings prior to the final release
]]>ICMC 2024 provided a valuable platform for industry leaders to engage in key discussions surrounding cryptographic standards, challenges, and innovations. Through our sponsorship, OpenSSL contributed to critical dialogues on post-quantum cryptography, regulatory compliance, and developing secure, open-source cryptographic solutions.
]]>Lightship Security, an Applus+ Laboratories company and a leading cryptographic security test lab, announces its agreement with the OpenSSL Corporation to provide FIPS 140-3 validation services for the OpenSSL cryptographic library.
The OpenSSL Corporation provides commercial support for users of the OpenSSL Library, a critical component of secure communications in enterprise technologies.
]]>You can explore the dashboard here: OpenSSL Performance Benchmarks Dashboard. Additionally, it can be conveniently accessed from the main menu of this site under the “Resources” section.
]]>We’ve recently been receiving a lot of questions about these new standards so we wanted to make our position clear:
From early 2022 a research project made available a test vehicle enabling TLS1.3 and X.509 support for many pre-standard and other experimental post-quantum algorithms via the OpenSSL provider interface, called oqs-provider. Its primary author and maintainer (Michael Baentsch) has now joined the OpenSSL team with the goal to support an efficient, secure, smooth and seamless integration of the now standardised post-quantum algorithms from NIST into the OpenSSL code base. Many lessons learnt from the process of building and integrating oqs-provider into downstream applications will be applied to this process.
]]>Our Alpha releases are considered feature complete for the release, meaning that between now and the final release, only bug fixes are expected (if any). Notable features of this release are available in CHANGES.md within the source tarball.
Alpha releases are provided to our communities for testing and feedback purposes. If you use OpenSSL, and particularly if you intend to upgrade to OpenSSL 3.4 when it is released, we strongly encourage you to download this alpha release, and test it within whatever quality control mechanisms you have, providing feedback via our GitHub issue page at http://github.com/openssl/openssl/issues, so that we can address any shortcomings prior to the final release
]]>Feedback on the proposal was generally split down the middle, with half of the respondents indicating immediate depreciation with near-term removal was acceptable, while the remainder of the respondents with affirmative opinions noted that they represent, or know of products whose environment disallowed updating to TLS1.2 or later, and would need to re-enable the deprecated features for the foreseeable future.
]]>Date: September 11, 2024
Time: 09:00 AM Pacific Time (US and Canada)
Platform: Zoom
Topic: Debugging OpenSSL Applications
Registration Link: Click here to register
For professionals dealing with OpenSSL, mastering these debugging techniques is essential to ensuring the stability and security of their applications.
]]>Conference Name: International Cryptographic Module Conference
Dates: 18th - 20th September 2024
Location: DoubleTree by Hilton, San Jose, California
Our Booth Number: 102
Alpha freeze approaching
The freeze date for OpenSSL 3.4 Alpha is rapidly approaching. Planned features are viewable on our 3.4 Planning page. If you have a feature on the planning page, please ensure that your associated PRs are posted, reviewed, and merged prior to the freeze date (Friday, Aug 30, 2024), or it will be postponed until the next release.
]]>New Governance Framework
OpenSSL has two independent, co-equal organizations to support the OpenSSL Mission:
This balanced approach ensures that both entities can operate independently and make decisions autonomously.
]]>OpenSSL is hiring for a Fundraiser to join our team
We are seeking a Fundraiser to join our team. As a Fundraiser at OpenSSL, you will play a vital role in sustaining critical components of internet infrastructure that enable secure communications around the world. In addition to your fundraising role, you must align with and uphold our core values and mission in your every day professional activities. This role will require you to have strong networks and relationships with our various sponsors, customers and communities in order to help us identify and bring on board new sponsors for our project as well as maintain our existing ones. You will also hold significant responsibility for developing our sponsorship and fundraising program in order to ensure that our sponsors are getting good value from their engagement with us whilst at the same time maximizing the resources available to OpenSSL to further develop and expand.
]]>Date: August 1, 2024
Time: 09:00 AM Pacific Time (US and Canada)
Platform: Zoom
Topic: Performance Tuning with OpenSSL
Registration Link: Click here to register
]]>Over the years, the combintation of Postfix and Mailman has served us well, but it’s time to move on and explore better options. Google Groups offers several advantages that align with our goals:
]]>Recently, some may have noticed issues (particularly old ones) in the openssl repository have received an update, having the ‘inactive’ label applied to them with a comment indicating that they will be closed at the end of the 3.4 development cycle. OpenSSL currently has almost 2000 outstanding issues in its issue list, many of which have been sitting idle for multiple years. In an effort to better plan and schedule work for the OpenSSL development team, it has become increasingly clear that, to do so efficiently, the issue list must be reduced, so as to better identify those issues which are impacting the larger user base more visibly for planning purposes.
]]>In this brief yet comprehensive session, we’ll dive into the basics of QUIC and guide you through implementing a simple client using the QUIC OpenSSL API. By the end of this webinar, you’ll have a solid grasp of creating a client application that connects to a server and receives data. Our demo client may be straightforward, but it serves as the perfect playground to explore and observe the QUIC protocol in action. Get ready to see QUIC in motion and discover the tools to monitor its performance effectively!
]]>This preview is now available in the feature/quic-server branch of
the OpenSSL repository on GitHub. Those interested in providing early feedback
on our QUIC server functionality are invited to download and build this branch.
It is important to note that this branch represents a prototype phase at this time and many aspects of the planned functionality are not yet implemented. In particular, only a very small subset of the full SSL API is currently implemented. This preview is being released to enable all of our communities to provide their feedback as part of the API design process and in order to validate our requirements prior to the finalisation of the API.
]]>OpenSSL 3.3 delivers the following new features:
OpenSSL 3.3 is a regular release, upon this final release a one-year Full Support period is initiated for regular releases. During this phase, bugs and security issues are addressed and fixed according to the Stable Release Updates Policy. Immediately after the Full Support phase ends, the Maintenance Support phase begins, lasting for one year. During this phase, the primary focus is on fixing security issues, although other bugs may be addressed at the discretion of OpenSSL engineering.
]]>We appreciate the support of all our communities, users, individual contributors and support customers, without which we would not be able to continue our mission and deliver on our open source values. These continue to drive the success and evolution of OpenSSL, and we couldn’t be more appreciative.
]]>
FOSDEM, short for Free and Open Source Software Developers’ European Meeting, is an event that brings together thousands of open source developers, enthusiasts, and professionals from around the world. It’s a festival of knowledge, with workshops, talks, and sessions covering a myriad of topics from software development and security to hardware innovation and beyond.
]]>This webinar is designed to take you from an understanding of basic cryptography concepts to writing your first secure application using OpenSSL. It’s the perfect starting point for anyone looking to dive into the world of secure application development. Here’s what we’ll cover:
By the end of this presentation, the audience should be able to match their application needs to OpenSSL library features, find documentation to explain how to leverage those features, create applications using OpenSSL, and learn how to detect and understand errors that may arise.
]]>OpenSSL 3.3 will feature the following new features:
No further features or API changes are planned for 3.3 beyond those listed above. We will not be accepting any additional features for 3.3; any unmerged feature PRs will now be considered for 3.4.
]]>The release schedule is as follows:
An alpha of OpenSSL 3.3 will be made on 20 March 2024.
A beta of OpenSSL 3.3 will then be made on 29 March 2024.
The expected final release date for OpenSSL 3.3.0 is 10 April 2024. Backup release dates are 17 April 2024 and 24 April 2024.
]]>NetApp’s sponsorship brings valuable resources to OpenSSL, enabling the project to accelerate development, conduct thorough security audits, and ensure ongoing maintenance and support. In return, NetApp gains access to cutting-edge cryptographic technologies, contributing to the enhancement of its own security solutions and reinforcing its position as a leader in data management.
]]>Why Attend? Empower Yourself: Gain practical skills to implement OpenSSL in your projects. Community Engagement: Connect with a community of security-conscious individuals.
]]>This in no way impacts our existing FIPS 140-2 certificate which remains valid and will be maintained until its sunset date in September 2026.
]]>What to Expect:
Tutorial Series: Get ready for in-depth tutorials covering a wide range of topics, from OpenSSL basics to advanced usage scenarios. Whether you’re a seasoned developer or just starting, our tutorials will cater to all skill levels.
]]>To express our gratitude to the incredible community that has supported us throughout the years, we are hosting an exclusive T-Shirt Giveaway! The first 75 people to participate will receive a limited edition OpenSSL 25th-anniversary T-shirt as a token of our appreciation.
]]>Due to a small number of bugs which have been identified by the ongoing use of fuzzing, the OpenSSL Project has made the decision to postpone the final release of OpenSSL 3.2 by at least a week. While we have promptly fixed all bugs presently identified by fuzzing, to ensure the quality of OpenSSL 3.2, we do not intend to make the final release until all issues identified by fuzzing have been addressed and no new issues are found for one week. As a result, we have pushed the full release of OpenSSL 3.2 to the 23rd November 2023. Please stay tuned to our blog for more details on the matter.
]]>In the meantime the OpenSSL 3.2 Beta is currently available. We encourage all OpenSSL users to build and test against the beta release and provide feedback.
OpenSSL 3.2 will be our last release before we transition to a time-based release schedule on a 6-month cadence, with regular feature releases in October and April each year.
]]>The code for OpenSSL 3.2 is now functionally complete and at the time of the beta release there were no outstanding known regressions that need to be fixed before the final release. A lot of work has been going on over the last few months getting OpenSSL 3.2 ready for its final release and we want to send thanks to everyone who has helped us.
]]>Raw Public Keys are a cryptographic mechanism used in public key infrastructure (PKI) systems. They are a way of representing a public key without the associated digital certificate, which contains additional information like the owner’s identity, expiration date, and digital signatures from a certificate authority. This makes Raw Public Keys more lightweight and efficient, especially in resource-constrained environments.
]]>Hybrid Public Key Encryption (HPKE) is a cryptographic protocol defined in RFC 9180 (Request for Comments) that aims to provide a flexible and secure way to perform public key encryption in various scenarios. HPKE combines the security of public key encryption with the flexibility of using different key exchange methods and encryption schemes. This protocol is designed to be used in a wide range of applications, including securing communications over the internet and other networked environments.
Implementing HPKE in OpenSSL will help ensure that your public key encryption solution is both effective and reliable for securing data in various applications and environments for the following reasons:
]]>Please see our previous blog post for a list of all of the exciting new features that are contained in the upcoming 3.2 release.
]]>As this will be an alpha release, it is intended for development and testing purposes. It represents the first step in our planned release of OpenSSL 3.2.
Depending on the outcome of the alpha process, we hope to make a beta release as soon as two weeks after Alpha 1 is released. When we do move to beta, this will represent a feature freeze. Therefore, no new feature PRs will be accepted into the 3.2 branch after this.
]]>These updates are part of our effort to align more closely with, and live by, our Mission and Values.
]]>This blog post provides information and advice for users of OpenSSL. Specifically, it provides information on how users of OpenSSL may be affected by these vulnerabilities, and advice for users of OpenSSL on mitigation strategies.
]]>You can view our new Mission and Values Statment here.
We would like to extend our sincere thanks to all those who provided feedback to us. We have reviewed all the comments and responses, which showed that a clear majority (around 70%) agreed on OpenSSL adopting the Mission and Values Statement. It was really beneficial to hear from our various communities and we will continue to seek out your feedback in the future.
]]>We’d like to get even more feedback so we are extending the response period until 19th May 2023. If you haven’t already provided feedback to us, please do so by:
As a small incentive we will be randomly selecting 10 responders out of everyone who has provided feedback and the lucky ones will receive an OpenSSL T-shirt. (Yes this includes those who have already responded to us).
]]>Please read the advisory for specific details about these CVEs and how they might impact you. This blog post will address some common questions that we expect to be asked about these CVEs.
]]>UPDATE: The post was updated to mention the new CVE-2022-40735 vulnerability.
]]>legacy provider, to be loaded optionally by
those wishing to still use any of said algorithms.]]>See FIPS 140-2 Certificate here
]]>Local side channel attacks, such as these, are outside the scope of our security policy, however the project generally does introduce mitigations when they are discovered. In this case, the OTC has decided that these attacks will not be mitigated by changes to the OpenSSL code base. The full reasoning behind this is given below.
]]>Since then there has been much design work taking place and we are now able to publish the draft design documentation. You can read about how we see the longer term architecture of OpenSSL changing in the future here and you can read about our specific plans for OpenSSL 3.0 (our next release which will include a FIPS validated module) here.
]]>The current versioning scheme has this format:
MAJOR.MINOR.FIX[PATCH]
The new scheme will have this format:
MAJOR.MINOR.PATCH
In practical terms our “letter” patch releases become patch numbers and “fix” is dropped from the concept. In future, API/ABI compatibility will only be guaranteed for the same MAJOR version number. Previously we guaranteed API/ABI compatibility across the same MAJOR.MINOR combination. This more closely aligns with the expectations of users who are familiar with semantic versioning. We are not at this stage directly adopting semantic versioning because it would mean changing our current LTS policies and practices.
]]>Four weeks ago, the OpenSSL team gathered with many of the organisations sponsoring the next FIPS module for a face-to-face meeting in Brisbane, Australia.
We got a great deal accomplished during that week. Having most of the fips-sponsor organisations in the same location helps ensure that we are all on the same page for the decisions we need to make going forward.
]]>OpenSSL 1.1.1 has been a huge team effort with nearly 5000 commits having been made from over 200 individual contributors since the release of OpenSSL 1.1.0. These statistics just illustrate the amazing vitality and diversity of the OpenSSL community. The contributions didn’t just come in the form of commits though. There has been a great deal of interest in this new version so thanks needs to be extended to the large number of users who have downloaded the beta releases to test them out and report bugs.
]]>We have now added a new OMC member and two new committers.
]]>“That we remove “We strongly believe that the right to advance patches/info should not be based in any way on paid membership to some forum. You can not pay us to get security patches in advance.” from the security policy and Mark posts a blog entry to explain the change including that we have no current such service.”
At the OpenSSL Management Committee meeting earlier this month we passed the vote above to remove a section our security policy. Part of that vote was that I would write this blog post to explain why we made this change.
]]>For background, you can see all posts in the license tag.
One copy of the press release is at https://www.prnewswire.com/news-releases/openssl-seeking-last-group-of-contributors-300607162.html.
]]>The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3. The new release will be binary and API compatible with OpenSSL 1.1.0. In theory, if your application supports OpenSSL 1.1.0, then all you need to do to upgrade is to drop in the new version of OpenSSL when it becomes available and you will automatically start being able to use TLSv1.3. However there are some issues that application developers and deployers need to be aware of. In this blog post I am going to cover some of those things.
]]>But before we can even discuss this as an option we would have to change our public stance. Our security policy since 2014 has stated we would not do this and currently reads:
]]>One of the overall threads of the meeting was about increasing the transparency of the project. By default, everything should be done in public. We decided to try some major changes to email and such.
]]>The Levchin prize for Real World Cryptography recognises up to two groups or individuals each year who have made significant advances in the practice of cryptography and its use in real-world systems. This year one of the two recipients is the OpenSSL team. The other recipient is Hugo Krawczyk.
]]>The OpenSSL Management Committee (OMC) would like to wish him all the best for the future.
All communication that used to go to Steve Marquess directly, should now be sent to info@openssl.org in the first instance.
Thanks for your contributions to the project over the years!
]]>RAND API. The default RAND method is now based
on a Deterministic Random Bit Generator (DRBG) implemented according to
the NIST recommendation 800-90A.
We have also edited the documentation, allowed
finer-grained configuration of how to seed the generator, and updated
the default seeding mechanisms.
There will probably be more changes before the release is made, but they should be comparatively minor.
Read on for more details.
]]>With TLS 1.3 now done (pending only a final TLS 1.3 specification) we’re now in a position to turn our attention to the new FIPS module, and just in the nick of time Oracle has pledged enough funding to get us off to a good start. With financial support from the Linux Foundation Core Infrastructure Initiative temporarily interrupted, leaving a team member with no income, that funding eases the pressure to seek new long term employment.
]]>So far, about 40% of the people have responded. For a project that is as old as OpenSSL (including its predecessor, SSLeay, it’s around 20 years) that’s not bad. We’ll be continuing our efforts over the next couple of months to contact everyone.
Of those people responding, the vast majority have been in favor of the license change – less then a dozen objected. This post describes what we’re doing about those and how we came to our conclusions. The goal is to be very transparent and open with our processes.
]]>Now that we have in place committer guidelines, we have invited the first set of external (non-OMC) community members to become committers and they have each accepted the invitation.
]]>The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3. The new release will be binary and API compatible with OpenSSL 1.1.0. In theory, if your application supports OpenSSL 1.1.0, then all you need to do to upgrade is to drop in the new version of OpenSSL when it becomes available and you will automatically start being able to use TLSv1.3. However there are some issues that application developers and deployers need to be aware of. In this blog post I am going to cover some of those things.
]]>In the next few days we’ll start sending out email to all contributors asking them to approve the change. In the meantime, you can visit the licensing website and search for your name and request the email. If you have changed email addresses, or want to raise other issues about the license change, please email license@openssl.org. You can also post general issues to openssl-users@openssl.org.
We are grateful to all the contributors who have contributed to OpenSSL and look forward to their help and support in this effort.
The official press release can be found at the CII website. The rest of this post is a copy:
]]>While none of the behaviors have really changed, and therefore none of this should be new information, the documentation has not been as clear as it could, or should, be. Therefore, some readers might be surprised by what’s in this post.
In short, OpenSSL has always, and only, supported the concept of locking an object and sometimes it locks its internal objects. Read on for more details.
]]>We updated the project roadmap.
I think the most important news here, is that our next release will include TLS 1.3. Our current plan is that this will be 1.1.1, which means that it is API-compatible with the current 1.1.0 release. This is really only possible because of the work we did on making most of the structure internals opaque. Also, since we are doing all of our work in public on our GitHub repository, we hope that the entire community will be able to “follow along at home” and help us improve the code. There will be more, much more, to say about this later.
]]>We got a great deal accomplished during that week. We do many things by vote, and having everyone in the room to talk not only beats email all to hell, but it ensures that we’re all on the same page for the decisions we make. Sure, not everything was a unanimous decision, but none were decided by narrow margins.
In this post I’m going to talk about two important decisions.
]]>This post gives a bit of background and describes what OpenSSL is doing. For more details, see their website.
]]>Multiple commercial vendors have offered to fund (very generously in some cases) a new validation effort under terms that would guarantee them a proprietary validation, while not guaranteeing an open source based validation. At one point we actually came close to closing a deal that would have funded an open source based validation attempt in exchange for a limited period of exclusivity; a reasonable trade-off in my opinion. But, I eventually concluded that was too risky given an uncertain reception by the FIPS validation bureaucracy, and we decided to wait for a “white knight” sponsor that might never materialize.
]]>Over the past weeks, the OpenSSL team worked closely with the researchers to determine the exact impact of DROWN on OpenSSL and devise countermeasures to protect our users. Today’s OpenSSL release makes it impossible to configure a TLS server in such a way that it is vulnerable to DROWN.
]]>It doesn’t matter much what digest algorithm we choose. Being lazy, I’ve chosen one with a well defined reference implementation, MD5 (reference implementation is found in RFC 1321)
]]>The least boilerplate code for an engine looks like this:
#include <openssl/engine.h>
IMPLEMENT_DYNAMIC_BIND_FN(bind)
IMPLEMENT_DYNAMIC_CHECK_FN()
This example isn’t complete, it will not compile. However, it contains the absolute minimum required for those module to even be recognised as an OpenSSL engine.
]]>Nothing could be further from the truth. Also, having the engine for some hardware bundled with the OpenSSL source presents a maintainance problem, and the better solution is for those who have an engine to maintain theḿ themselves.
]]>After introducing the new policy we started giving everyone a headsup when we were due to release OpenSSL updates that included security fixes. The headsup doesn’t contain any details of the issues being fixed apart from the maximum severity level and a date a few days in the future.
]]>The v2.0 OpenSSL FIPS module is compatible with the 1.0.x releases, in particular the 1.0.2 “LTS” release that will be supported through 2019. It has proven very popular, used both directly by hundreds of software vendors and indirectly as a model for copycat “private label” validations.
]]>In September 2014, the team adopted a security policy that defines how we handle vulnerability reports. One year later, I’m very happy to conclude that our policy is enforced, and working well.
Our policy divides vulnerabilities into three categories, and defines actions for each category: we use the severity ranking to balance the need to get the fix out fast with the burden release upgrades put on our consumers.
]]>The text still needs more work. As someone on the team pointed out, “a worldwide community of volunteers that use the Internet to communicate, plan, and develop [OpenSSL]” … really?
]]>Things have evolved since then, and open source is an important part of the landscape – the Internet could not exist without it. There are good reasons why Microsoft is a founding member of the Core Infrastructure Initiative (CII).
Our plan is to update the license to the Apache License version 2.0. We are in consultation with various corporate partners, the CII, and the legal experts at the Software Freedom Law Center. In other words, we have a great deal of expertise and interest at our fingertips.
]]>These updates fix a number of Moderate and Low severity security issues in OpenSSL. They also fix one new High severity issue, CVE-2015-0291, that affects just OpenSSL 1.0.2, released in January this year. A remote attacker could use this flaw to cause unfixed servers to crash, which could lead to a denial of service attack depending on the server.
]]>The goal of this post is to list the requirements. It’s definitely incomplete and will evolve over time. Post your questions and comments and help refine the list!
]]>Powered by Octopress. Take a bit of doing to get it running.
Whew.
#include <stdio.h>
int
main(int ac, char *av[])
{
printf("Hello, world\n");
return 0;
}