OpenSSL Library

Business Advisory Committees Elections Are Now Open - Vote for Your Community Representative

Thank you to everyone who registered, as well as those who took the extra step to nominate candidates, for the Business Advisory Committees of the OpenSSL Foundation and OpenSSL Corporation. We are now at the final step - voting - which is essential to complete the process. 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.

Nominations Remain Open Until Wednesday, December 4, 2024 - Based on Your Feedback!

Thank you to everyone who attended our Q&A sessions about the formation of Business Advisory Committees. We received valuable input from our communities, including requests to allow more time for nominations. We have heard you, and we would like to announce that: The nomination period has been extended until Wednesday, December 4, 2024. The election period starts on Thursday, December 5, 2024 and ends on Sunday, December 15, 2024. You can change your vote up to the end of the election period.

Websites mirrors

To align with our mission, we have provisioned mirrors for our websites, hosted through our chosen CDN vendor: https://mirror.openssl.org https://mirror.openssl-mission.org https://mirror.openssl-library.org https://mirror.openssl-foundation.org https://mirror.openssl-corporation.org https://mirror.openssl-projects.org https://mirror.openssl-conference.org These mirrors are accessible in locations where our original websites might be blocked.

Upcoming Webinar - Working with X.509 Keys and Certificates

Advance Your Skills in X.509 Certificate Management with OpenSSL Date: Nov 21, 2024 Time: 04:00 PM Eastern Time (US and Canada) Duration: 1 hour Location: Online Webinar (link to be provided upon registration) Register Here 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 Forms Business Advisory Committees - Shape the Future - Join Now!

The OpenSSL Foundation (primarily focused on non-commercial communities) and the OpenSSL Corporation (primarily focused on commercial communities) are pleased to announce the formation of Business Advisory Committees (BAC), inviting our communities - Distributions, Committers, Small Businesses, Large Businesses, Individuals, and Academics - to actively engage in shaping the future of OpenSSL. These advisory bodies are critical in enhancing our governance structure, ensuring that the decisions reflect the diverse stakeholders involved and that our Mission and Values stay aligned with the community’s needs.

OpenSSL 3.4 Final Release Live

The final release of OpenSSL 3.4 is now live. We would like to thank all those who contributed to the OpenSSL 3.4 release, without whom OpenSSL would not be possible. OpenSSL delivers the following significant new features: Support for Integrity only cipher suites (RFC 9150) JITTER RNG support via statically linked jitterentropy library RFC 5755 Attribute Certificate support FIPS indicators in support of FIPS 140-3 validation Improved Base64 BIO input handling and error reporting XOF Digest size reporting improvements Windows Registry key-based directory lookup Support for several X509v3 extensions Support for position independent executables in the openssl app to support address space layout randomization Please see the CHANGES.

OpenSSL is hiring Communities Manager

Please note that we are no longer accepting new applications for this position.

OpenSSL is hiring for a Communities Manager to join our team.

Introducing Amy Parker

OpenSSL welcomes Amy Parker as the newest member of the OpenSSL Foundation team. Amy joins us in the newly created position of Chief Funding Officer, a fundraising role focused on revenue generation through corporate sponsorship and other charitable/non-commercial contributions. Funds raised will help the Foundation continue to deliver on its mission of providing security and privacy tools to everyone, everywhere. 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.

OpenSSL 3.4 beta released

OpenSSL 3.4 beta 1 has now been made available. 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.

OpenSSL Corporation's Silver Sponsorship at ICMC 2024 - A Retrospective

OpenSSL Corporation’s participation as a Silver Sponsor at the International Cryptographic Module Conference (ICMC) 18th - 20th September 2024 marked an important milestone in our continued commitment to advancing cryptographic technologies. As a critical player in secure communication, OpenSSL’s involvement highlighted our dedication to fostering collaboration, innovation, and security within the cryptographic community. ICMC 2024 provided a valuable platform for industry leaders to engage in key discussions surrounding cryptographic standards, challenges, and innovations.

Lightship Security Partnership with OpenSSL

OpenSSL is sharing Lightship Security’s latest press release, highlighting the new partnership with the OpenSSL Corporation. Read the full release below: 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.

Performance benchmarks dashboard

We would like to announce the release of the OpenSSL Performance Benchmarks Dashboard, designed to track the impact of code changes on performance. The key focus of this dashboard is relative performance so we can assess how various code modifications affect OpenSSL’s performance across versions. This helps ensure that we’re aware of any potential performance impacts in advance, allowing us to maintain or improve efficiency with each update. You can explore the dashboard here: OpenSSL Performance Benchmarks Dashboard.

Post-Quantum Algorithms in OpenSSL

Recently NIST published a number of post-quantum algorithm standards (ML-KEM, ML-DSA, and SLH-DSA). With these new NIST publications, OpenSSL is now prepared for implementation. We’ve recently been receiving a lot of questions about these new standards so we wanted to make our position clear: We intend to implement support for these algorithms in our providers in a future version of OpenSSL We are currently putting together our project plans for this, stay tuned for more information regarding timeline We invite qualified and skilled individuals to help us implement these algorithms and integrate them into OpenSSL in accordance with our standards and policies.

OpenSSL 3.4 alpha released

OpenSSL 3.4 alpha 1 has now been made available. 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.

OpenSSL considering TLS 1.0/1.1 deprecation

Recently, OpenSSL proposed the deprecation of TLS 1.0/1.1 and solicited community feedback on the idea. 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.

Join Our Webinar on Debugging OpenSSL Applications

Debugging is a crucial aspect of developing and maintaining reliable software. However, debugging can become particularly challenging when applications incorporate diverse and complex components like OpenSSL. This webinar is designed to help you navigate these complexities. Webinar Details: 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 What to Expect: Internal Debugging Tools: Learn about the facilities OpenSSL provides to help you gain visibility into its internal behavior, allowing for more effective troubleshooting.

Join OpenSSL at the ICMC 2024 - Visit Our Exhibit Booth!

OpenSSL is pleased to announce its participation as a Silver Sponsor at the upcoming International Cryptographic Module Conference (ICMC) 2024, taking place from 18th to 20th September. Visit our booth and attend our presentations to discover how we can help each other. Event Details: Conference Name: International Cryptographic Module Conference Dates: 18th - 20th September 2024 Location: DoubleTree by Hilton, San Jose, California Our Booth Number: 102 About the ICMC The ICMC is a leading event in the cryptographic community, bringing together experts from around the world to discuss the latest trends, innovations and challenges in cryptographic modules.

Join OpenSSL at the ICMC 2024 - Visit Our Exhibit Booth!L

OpenSSL 3.4 Alpha release approaching

The freeze date for OpenSSL 3.4 Alpha is rapidly approaching. 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 Structure and New Projects under the Mission

As part of our ongoing journey, OpenSSL is evolving to provide more opportunities for engagement that more effectively align with our mission statement and promote our values. OpenSSL is implementing various mechanisms to foster greater community involvement and enable our communities to play a key and active role in the decision-making process. New Governance Framework OpenSSL has two independent, co-equal organizations to support the OpenSSL Mission: The OpenSSL Foundation primarily focuses on non-commercial communities.

OpenSSL is hiring - Fundraiser

Note that this position has now been filled and we are no longer accepting applications 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.

Join Our Exclusive Webinar on Performance Tuning with OpenSSL

Secure communication is vital in today’s digital world, but it sometimes slows down your applications. We invite you to an insightful webinar on optimizing application performance using OpenSSL. This session is designed for individuals seeking to enhance the security and efficiency of their applications. Webinar Details: 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

OpenSSL mailing lists are moving to Google Groups

We are announcing a change in how communication and collaboration will take place within the OpenSSL community. Effective August 1st, 2024, the OpenSSL mailing lists will migrate to Google Groups. This transition is designed to streamline communication channels and simplify our infrastructure. Why the change? 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:

Performance Tuning and Fetching with OpenSSL

Large issue cleanup in OpenSSL

OpenSSL is cleaning up its issue backlog Whats going on? 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.

New OpenSSL patch releases available

New OpenSSL patch releases are available

Soliciting input regarding a potential hardening effort

OpenSSL is soliciting input on a hardening effort for our library. The details can be found here: https://github.com/openssl/openssl/discussions/24321

Upcoming Webinar: Getting Started with QUIC and OpenSSL

We are pleased to announce our upcoming webinar, Getting Started with QUIC and OpenSSL. 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.

OSTIF and Trail of Bits Complete Audit of OpenSSL

OpenSSL would like to announce the publication of the final report of a recent security audit conducted on the OpenSSL software library.

Releases distribution changes

I’d like to give you a heads-up about some changes we’re making at OpenSSL. We’re simplifying how you can get our software, and that means we’re phasing out some older methods that don’t quite fit with the way the web works today.

QUIC server preview branch available for testing and feedback

We are pleased to announce the availability of a feature preview for our OpenSSL QUIC server functionality. This is an early technology preview which is being published to seek feedback from our communities. 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.

Upcoming Webinar: Writing a TLS Client

We are pleased to announce our upcoming webinar, Writing a TLS Client.

OpenSSL 3.3 Final Release Live

The final release of OpenSSL 3.3 is now live. This is the first release in accordance with our adoption of biannual time-based releases. We would like to thank all those who contributed to the OpenSSL 3.3 release, without whom, OpenSSL would not be possible. OpenSSL 3.3 delivers the following new features: QUIC qlog diagnostic logging support Support for the non-blocking polling of multiple QUIC connections or stream objects Support for optimised generation of end-of-stream frames for QUIC connections Support for disabling QUIC event processing when making API calls Support for configuring QUIC idle timeout durations Support for querying the size and utilisation of a QUIC stream’s write buffer Support for RFC 9480 and RFC 9483 extensions to CMP Ability to disable OpenSSL usage of atexit(3) at build time Year 2038-compatible SSL_SESSION APIs Ability to automatically derive Chinese Remainder Theorem (CRT) parameters when requested Ability to ignore unknown algorithm names in TLS signature algorithm and group configuration strings Ability to configure a TLS 1.

Celebrating 25 Years of OpenSSL

We are pleased to announce that we have successfully distributed nearly 100 limited edition T-shirts commemorating the 25th anniversary of OpenSSL’s existence. 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.

OpenSSL 3.3 Beta Release Live

The beta release of OpenSSL 3.3 is now live. This release is in accordance with our adoption of biannual time-based releases. As this is a beta release, we consider this to be a release candidate and as such encourage all OpenSSL users to build and test against this beta release and provide feedback. It represents the second step in our planned release of OpenSSL 3.3. To view the full 3.3 release schedule please refer to this blog.

OpenSSL at FOSDEM 24

This year, we had the privilege of participating in FOSDEM for the first time. This offered us an opportunity to engage with the open source community at the conference, share our insights, and learn from the vast pool of knowledge that FOSDEM brings together. ![Photo of OpenSSL FOSDEM 2024 attendees] (/images/blog/FOSDEM_24.jpg) 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.

Upcoming Webinar: Writing Your First OpenSSL Application

We are thrilled to announce our upcoming webinar, Writing Your First OpenSSL Application. 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: Define the use cases for which OpenSSL can be used How to find documentation to learn how to use OpenSSL in applications How to write applications using OpenSSL How to test and verify functionality of OpenSSL applications How to identify and fix bugs in OpenSSL applications Q&A Session: Have your questions answered by our OpenSSL experts.

OpenSSL 3.3 Alpha Release Live

The Alpha release of OpenSSL 3.3 is now live. This release is in accordance with our adoption of biannual time-based releases. As this is an alpha release, it is intended for development and testing purposes. It represents the first step in our planned release of OpenSSL 3.3. To view the full 3.3 release schedule please refer to this blog. OpenSSL 3.3 will feature the following new features: QUIC qlog diagnostic logging support Support for the non-blocking polling of multiple QUIC connection or stream objects Support for optimised generation of end-of-stream frames for QUIC connections Support for disabling QUIC event processing when making API calls Support for configuring QUIC idle timeout durations Support for querying the size and utilisation of a QUIC stream’s write buffer RCU lock infrastructure for performance enhancements Support for RFC 9480 and RFC 9483 extensions to CMP Ability to disable OpenSSL usage of atexit(3) at build time Year 2038-compatible SSL_SESSION APIs Ability to automatically derive Chinese Remainder Theorem (CRT) parameters when requested Ability to ignore unknown algorithm names in TLS signature algorithm and group configuration strings Ability to configure a TLS 1.

OpenSSL 3.3 alpha release date announced

We are pleased to announce our schedule for the April release of OpenSSL 3.3. In accordance with our adoption of biannual time-based releases following the release of OpenSSL 3.2, this will be our first time-based release. 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.

NetApp and OpenSSL: Teaming Up for More Secure Internet

Exciting news in the world of online security! NetApp, an intelligent data infrastructure company, is now a Gold Sponsor of OpenSSL, showing their strong support for making the internet a safer place for everyone. 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.

Upcoming Getting Started with OpenSSL Webinar

In the fast-paced world of cybersecurity, the ability to secure digital assets is paramount. We’re excited to announce our upcoming webinar, “Getting Started with OpenSSL,” which is designed to provide attendee’s with a solid foundation in using OpenSSL to enhance the security of their applications and systems. Join us for this webinar and learn all about OpenSSL’s purpose, features, and components. Why Attend? Empower Yourself: Gain practical skills to implement OpenSSL in your projects.

OpenSSL FIPS provider 3.0.9 validated

The OpenSSL project is pleased to announce an update to its FIPS 140-2 certificate #4282. The certificate now validates the FIPS provider built from the 3.0.8 and 3.0.9 releases.

OpenSSL 3.1 FIPS Module has been submitted for validation

On 2023-12-29 we have submitted our FIPS 140-3 validation report to NIST’s Cryptographic Module Validation Program (CMVP).

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.

OpenSSL's Official Youtube Channel

We are thrilled to announce a major leap forward in our efforts to connect with the community and share valuable insights—OpenSSL now has its own YouTube channel! As a significant milestone in our commitment to transparency, education, and open-source collaboration, this channel will serve as a hub for engaging content, tutorials, and updates straight from the heart of OpenSSL. What to Expect: Tutorial Series: Get ready for in-depth tutorials covering a wide range of topics, from OpenSSL basics to advanced usage scenarios.

OpenSSL 25 Year Anniversary T-Shirt Giveaway

We are thrilled to announce a special celebration in honor of OpenSSL’s 25th anniversary! Two and a half decades of commitment to security, reliability, and open-source collaboration have made OpenSSL an indispensable tool in the world of digital communication. 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.

OpenSSL Providers Workshop: Authors Track

Part two of the OpenSSL Providers Workshop is next week! We have divided the workshop into two tracks the Users Track and the Authors Track. Please join us next week for part two of the workshop: Live OpenSSL Providers Workshop: Authors Track. As with the Users Track, we will be hosting two sessions of the Authors Track at different times to allow people from different time zones to be able to join our workshops live.

OpenSSL Providers Workshop: Users Track

The long anticipated OpenSSL Providers Workshop is finally here! We have divided the workshop into two tracks the Users Track and the Authors Track. Please join us next week for part one of the workshop: Live OpenSSL Providers Workshop: Users Track. Due to world wide interest, we will be hosting two sessions of the Users Track at different times to allow people from different time zones to be able to join our workshops live.

OpenSSL announces final release of OpenSSL 3.2.0

We are pleased to announce the immediate availability of OpenSSL 3.2.0. OpenSSL 3.2.0 is the first General Availability release of the OpenSSL 3.2 release line, and incorporates a number of new features, including:

Client-side QUIC support, including support for multiple streams (RFC 9000)
Certificate compression in TLS (RFC 8879), including support for zlib, zstd and Brotli
Deterministic ECDSA (RFC 6979)
Support for Ed25519ctx, Ed25519ph and Ed448ph (RFC 8032) in addition to existing support for Ed25519 and Ed448
AES-GCM-SIV (RFC 8452)
Argon2 (RFC 9106) and supporting thread pool functionality
HPKE (RFC 9180)
The ability to use raw public keys in TLS (RFC 7250)
TCP Fast Open (RFC 7413) support, where supported by the OS
Support for provider-based pluggable signature schemes in TLS, enabling third-party post-quantum and other algorithm providers to use those algorithms with TLS
Support for Brainpool curves in TLS 1.3
SM4-XTS
Support for using the Windows system certificate store as a source of trusted root certificates. This is not yet enabled by default and must be activated using an environment variable. This is likely to become enabled by default in a future feature release.

OpenSSL 3.2 Final Release Postponed

As part of the OpenSSL project’s commitment to deliver a secure and high quality cryptography toolkit, we routinely apply fuzzing to the OpenSSL codebase, which searches automatically for potential bugs in upcoming OpenSSL releases. This fuzzing process runs continuously and on an ongoing basis and as such, bugs can be identified by our fuzzing infrastructure at any time. 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.

Expected OpenSSL 3.2 Release Date

The OpenSSL Project is excited to announce that OpenSSL 3.2 is expected to be fully released on 16th November, 2023. 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.

OpenSSL 3.2 Release Candidate

The OpenSSL Project is excited to announce our first beta release of OpenSSL 3.2. We consider this to be a release candidate and as such encourage all OpenSSL users to build and test against this beta release and provide feedback. 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.

OpenSSL Adds Support for Raw Public Key (RFC7250)

Raw Public Keys have emerged as a component for securing communications between clients and servers. Raw Public Keys, as defined in RFC 7250, play a role in ensuring the confidentiality, integrity, and authenticity of data exchanged over the web. As a result OpenSSL will be adding support for Raw Public Keys in the upcoming OpenSSL 3.2.

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.

Implementing HPKE in OpenSSL 3.2

The upcoming OpenSSL 3.2 will be implementing Hybrid Public Key Encryption (HPKE) into the library.

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:

OpenSSL FIPS 140 Update

In the ever-evolving landscape of cybersecurity, staying ahead of potential threats is crucial. The OpenSSL project has been at the forefront of cryptographic security for decades, providing a robust toolkit that enables encryption, decryption, and other cryptographic functions. In the continuous pursuit of enhancing security and regulatory compliance, we want to share our updated ambitious FIPS (Federal Information Processing Standards) plans.

New OpenSSL Tutorials for OpenSSL 3.2 Release

We will be releasing a series of new tutorials in the upcoming OpenSSL 3.2 release to help new users of OpenSSL get a quick start on developing applications using the OpenSSL libraries. They will also be helpful to users wanting to try out the new client side QUIC capabilities.

OpenSSL 3.2 Alpha 2 released

OpenSSL 3.2 Alpha 2 has recently been released.

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.

OpenSSL 1.1.1 End Of Life

OpenSSL 1.1.1 series has reached its End of Life (EOL). As such it will no longer receive publicly available security fixes.

OpenSSL announces OpenSSL 3.2 Alpha 1

We are pleased to announce the immediate availability of OpenSSL 3.2 Alpha 1. This release incorporates a number of new features, most notably:

Client-side QUIC support, including support for multiple streams (RFC 9000)
Certificate compression in TLS (RFC 8879), including support for zlib, zstd and Brotli
Deterministic ECDSA (RFC 6979)
Support for Ed25519ctx, Ed25519ph, Ed448 and Ed448ph (RFC 8032) in addition to existing support for Ed25519
AES-GCM-SIV (RFC 8452)
Argon2 (RFC 9106) and supporting thread pool functionality
HPKE (RFC 9180)
The ability to use raw public keys in TLS (RFC 7250)
TCP Fast Open (RFC 7413) support, where supported by the OS
Support for provider-based pluggable signature schemes in TLS, enabling third-party post-quantum algorithm providers to use these algorithms with TLS
Support for Brainpool curves in TLS 1.3
SM4-XTS
Support for using the Windows system certificate store as a source of trusted root certificates. This is not yet enabled by default and must be activated using an environment variable. This is likely to become enabled by default in a future feature release.

OpenSSL announces imminent release of OpenSSL 3.2 Alpha 1

OpenSSL is pleased to announce the imminent release of OpenSSL 3.2 Alpha 1 on the 7th September 2023. 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.

OpenSSL Updates: A Few Steps Forward

At OpenSSL, we’re always learning and taking small steps, informed by both fresh ideas and the feedback we receive. Today, we’d like to share a couple of updates we hope will make things clearer and more collaborative for our community.

These updates are part of our effort to align more closely with, and live by, our Mission and Values.

OpenSSL statement on the recent Intel/AMD Downfall/Inception vulnerabilities

Last week marked the public announcement of the Downfall vulnerability in Intel CPUs and the Inception vulnerability in AMD CPUs. Both of these are microarchitectural side-channel attacks allowing an attacker with unprivileged execution on the same physical core as a victim process to extract confidential information from that process. 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.

Face-to-face meetings: OTC and Committers

From June 19-21, OpenSSL had a face-to-face event in Brno, Czech Republic, for OTC members and contributors. The event provided a valuable platform for productive meetings and discussions. The gathering brought together prominent individuals from the OpenSSL community, fostering robust and enlightening exchanges. This event served as a crucial opportunity for introspection and future planning, encouraging open dialogue on various facets of the OpenSSL project.

Face-to-face meetings: OTC and Committers, Day 3

Discussions were held about introducing a new time-based release policy for OpenSSL. This policy aims to improve the predictability of release schedules and content. Part of this discussion also touched on how to effectively plan and assess feature readiness before each release.
To enhance project management, the use of feature branches for more complex features was suggested. This idea was paired with the proposal to establish clearly defined criteria for the review and approval of code.
As part of improving decision-making within the project, dialogues were carried out on how to best select features for inclusion. The proposal to establish a review body, focused on making these decisions and prioritizing features, was also put forward.
Inspired by Apache’s practices, improvements to the existing security policy were considered and discussed.
As part of addressing the project’s technical debt, suggestions were made to discuss infallible locking and mandatory atomics. The goal was to streamline locking mechanisms and reduce code complexity.
Tomas Mraz and Dmitry Belyavsky held personal sessions where they discussed different approaches. Tomas delved into the approach of using decoupled low-level crypto libraries, while Belyavsky considered the potential for incorporating more pluggable elements within OpenSSL.
Richard Levitte highlighted several areas of technical debt that need addressing. These included issues with composite algorithm names, the functionality of Password-Based Encryption (PBE), and AlgorithmIdentifier parameters. He also proposed potential solutions to these identified issues.

Face-to-face meetings: OTC and Committers, Day 2

The OpenSSL project has some performance issues. These need to be addressed by setting performance standards and testing before making changes. The team has agreed to prioritize this process.
Technical debt is another problem that needs to be dealt with. The proposed solutions are:
- Setting performance targets.
- Improving inefficient data structures.
The team also discussed ways to improve engagement with the community, including:
- Updating the current outdated communication channels.
- Revamping the website.
- Creating a separate space for user queries and software issues.
- Starting to use GitHub Discussions for better communication.
Supporting different OpenSSL versions poses challenges. The team also discussed how to manage Long Term Support (LTS) releases.
When talking about the QUIC protocol, several points were emphasized:
- Its development is crucial.
- Features need to be prioritized.
- It’s important to gather feedback early.
- There was agreement to turn on QUIC by default in the next release.
Nicola Tuveri pointed out that the BIGNUM issue needs to be addressed. He suggested setting aside dedicated resources to work on it.
Code reviews are essential for maintaining the quality of the project. Documentation should be easy to understand and useful for users. The team stressed its importance.
The error API has some problems. These were discussed along with potential solutions.

Face-to-face meetings: OTC and Committers, Day 1

The OTC retrospective highlighted the need for diversity and improved communication.
- A proposal for a Special Interest Group (SiG) model was made.
- The necessity for regular communication with communities was identified.
- A need for reevaluation of membership criteria was highlighted.
The team acknowledged the presence of technical debt in OpenSSL. Challenges like code redundancy and inconsistent APIs were noted within OpenSSL. Refactoring was seen as a potential solution to these OpenSSL challenges.
Updates and improvements to the Certificate Management Protocol (CMP) were discussed. Focus was placed on interoperability and testing within the CMP.
Red Hat engineers shared their journey towards FIPS compliance. Their approach to security vulnerabilities was discussed.
Solutions for managing parameters and configurations were examined.
The challenge of accessing entropy sources was discussed. A proposition to enhance randomness providers was made.
The implementation of Post-Quantum Cryptography was also discussed. Focus was put on compatibility between OQS and OpenSSL in the future.
Red Hat presented several significant issues, including confirmed bugs. There was also a discussion on features needing careful consideration by Red Hat.
The experience of writing a PKCS#11 provider emphasized the need for better documentation. The need for more supportive resources for writing a PKCS#11 provider was also discussed.

Who writes OpenSSL?

For a meeting last week I wanted to show how much of OpenSSL is being written by people paid to do so by their employers, and how much was from individuals in their own time. And it turns out most of OpenSSL is written by people paid to do so. This is crucial to understanding the critical role that corporations provide to Open Source projects such as OpenSSL.

OpenSSL 1.1.1 End Of Life Approaching

OpenSSL 1.1.1 series will reach End of Life (EOL) on 11th September 2023. Users of OpenSSL 1.1.1 should consider their options and plan any actions they might need to take.

Rebranded OpenSSL FIPS certificates issued

The OpenSSL project is pleased to announce that the first of the rebranded FIPS 140-2 certificates, available exclusively to our Premium Support Customers, have been officially issued by the CMVP. With this significant milestone achieved, we anticipate a smooth and ongoing rollout of the remaining and future rebrandings. If your company desires a rebranded FIPS 140-2 validation certificate bearing your organisation’s name, obtaining one is a straightforward task: simply secure a premium support contract with the project and ask for a rebranded certificate.

OpenSSL FIPS provider 3.0.8 validated

The OpenSSL project is pleased to announce a major update to its FIPS 140-2 certificate #4282. The certificate now validates the FIPS provider built from the 3.0.8 release.

OpenSSL 1.1.1 End Of Life

We are now less than 6 months away from the End Of Life (EOL) date for the OpenSSL 1.1.1 series. Users of OpenSSL 1.1.1 should consider their options and plan any actions they might need to take.

OpenSSL FIPS Update and Expansion of Rebranding Offer

We are thrilled to inform you that the complimentary FIPS rebranding service for our premium support customers has been extended. As part of this non-contractual benefit, premium support customers are entitled to one rebranding of any of our FIPS provider certificates per year, completely free of charge.

OpenSSL 3.1 Final Release

We are pleased to announce that the forthcoming OpenSSL 3.1 release is to be made available on 14th March 2023.

OpenSSL 3.1 Release Candidate

The OpenSSL Management Committee (OMC) and the OpenSSL Technical Committee (OTC) are glad to announce our first beta release of OpenSSL 3.1. We consider this to be a release candidate and as such encourage all OpenSSL users to build and test against this beta release and provide feedback.

OpenSSL 3.1 alpha release

The OpenSSL Management Committee and the OpenSSL Technical Committee are glad to announce the alpha release of OpenSSL 3.1.

CVE-2022-3786 and CVE-2022-3602: X.509 Email address buffer overflows

Today we published an advisory about CVE-2022-3786 (“X.509 Email Address Variable Length Buffer Overflow”) and CVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”).

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.

Configuring supported TLS groups in OpenSSL

The configuration of supported groups in TLS servers is important to limit the resource consumption of the TLS handshakes performed by the server. This blog post should give system administrators a few useful hints on how to configure the OpenSSL library and two of the most used open source HTTP servers which use the OpenSSL library for supporting the HTTPS protocol.

UPDATE: The post was updated to mention the new CVE-2022-40735 vulnerability.

RIPEMD160 and the legacy provider

With the release of OpenSSL 3.0 and the new provider architecture, some algorithms that were considered legacy by the OpenSSL team at the time were moved to the legacy provider, to be loaded optionally by those wishing to still use any of said algorithms.

FIPS 140-3 Plans

The OpenSSL Management Committee (OMC) on behalf of the OpenSSL Project is pleased to announce that the project is partnering with KeyPair Consulting and Acumen Security to validate OpenSSL to meet the requirements of the FIPS 140-3 standard.

OpenSSL Presentation at ICMC22 Conference

After 2 years of forced covid break, OpenSSL once again presented at the ICMC22 conference. The conference was a very pleasant meet-up of the community around cryptography and cryptographic modules. There were a lot of insights, feedback, and discussions around IT security. OpenSSL gave a talk on the Current Status of OpenSSL.

OpenSSL 3.0 FIPS 140-2 Free Rebranding Offer

OpenSSL is celebrating our FIPS 140-2 certification with a special offer for our Premium Support Customers by providing access to a free rebranding of the OpenSSL 3.0 FIPS 140-2 certificate.

See FIPS 140-2 Certificate here

OpenSSL FIPS 140-2 validation certificate issued

The OpenSSL Management Committee on behalf of the OpenSSL Project is pleased to announce that the OpenSSL 3.0 FIPS Provider has had its FIPS 140-2 validation certificate issued by NIST & CSE.

Spectre and Meltdown Attacks against OpenSSL

The OpenSSL Technical Committee (OTC) was recently made aware of several potential attacks against the OpenSSL libraries which might permit information leakage via the Spectre attack.¹ Although there are currently no known exploits for the Spectre attacks identified, it is plausible that some of them might be exploitable.

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.

Starting the QUIC design

The OTC recently agreed a new design process that needs to be followed for future releases. See here for details. Moving forward designs for significant features should be captured and stored alongside the documentation in our main source code repository and updated if necessary during the development process.

OpenSSL Update

The OpenSSL community is a diverse group, ranging from those that use applications that depend on OpenSSL (effectively end-users) to operating system distributions, application developers, embedded devices, layered security libraries, and cryptographic algorithm and protocol researchers. Each of these subsets of our community have different needs and different priorities.

Making changes to OpenSSL technical policies more open

The OpenSSL Technical Committee decided to have a more formal but also a more open process on establishing changes to OpenSSL technical policies and other technical decisions made by the OpenSSL Technical Committee. We would like to invite the broad community of OpenSSL developers and users to participate in our decision making process.

Community Maintainers: How to get support for your platform

The OpenSSL project is seeking community maintainers to assist with supporting platforms that the project is unable to.

If you have a platform that you’d like to see supported which isn’t a primary or secondary platform as per our platform policy, you should consider stepping up as a community maintainer.

OpenSSL 3.0 FIPS Module has been submitted for validation

Following on from the recent announcement that OpenSSL 3.0 has been released, we have now also submitted our FIPS 140-2 validation report to NIST’s Cryptographic Module Validation Program (CMVP).

Old Let's Encrypt root certificate expiration and OpenSSL 1.0.2

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30. In some cases the OpenSSL 1.0.2 version will regard the certificates issued by the Let’s Encrypt CA as having an expired trust chain.

OpenSSL 3.0 has been released!

After 3 years of development work, 17 alpha releases, 2 beta releases, over 7,500 commits and contributions from over 350 different authors we have finally released OpenSSL 3.0! In addition to this there has been a large number of contributions from our users who have been actively working with the pre-release versions to test it, make sure it works in the real world and with a large array of different applications and reporting their results. I am also delighted to note that there has been a 94% increase in the amount of documentation that we have since OpenSSL 1.1.1 and an (adjusted) increase in the “lines of code” in our tests of 54%. There has never been a better demonstration of what an active and enthusiastic community we have than when you look at the statistics for the OpenSSL 3.0 development work. Thanks to everyone who has taken part - no matter how small that part was.

OpenSSL 3.0 Release Candidate

The OpenSSL Management Committee (OMC) and the OpenSSL Technical Committee (OTC) are glad to announce our first beta release of OpenSSL 3.0. We consider this to be a release candidate and as such encourage all OpenSSL users to build and test against this beta release and provide feedback.

OpenSSL 3.0 alpha7 release

The OpenSSL Management Committee (OMC) and the OpenSSL Technical Committee (OTC) are glad to announce the seventh alpha release of OpenSSL 3.0.

OpenSSL 3.0 alpha4 release

The OpenSSL Management Committee and the OpenSSL Technical Committee are glad to announce the fourth alpha release of OpenSSL 3.0.

OpenSSL 3.0 alpha3 release

The OpenSSL Management Committee and the OpenSSL Technical Committee are glad to announce the third alpha release of OpenSSL 3.0.

OpenSSL 3.0 alpha2 release

The OpenSSL Management Committee and the OpenSSL Technical Committee are glad to announce the second alpha release of OpenSSL 3.0.

Security Policy Update on prenotifications

We’re planning to extend who we prenotify of any future High and Critical security issues.

OpenSSL 3.0 alpha1 release

The OpenSSL Management Committee and the OpenSSL Technical Committee are glad to announce the first alpha release of OpenSSL 3.0.

QUIC and OpenSSL

QUIC is a new protocol which the IETF talks about as A UDP-Based Multiplexed and Secure Transport, and has attracted a lot of attention lately. The OpenSSL Management Committee (OMC) have followed the development with interest, and we feel that we owe it to the community to say where we stand on this, and on the inclusion of support for this protocol in our libraries.

Update on 3.0 Development, FIPS and 1.0.2 EOL

We have previously talked about our plans for OpenSSL 3.0 and FIPS support here. This blog post will give an update about what has been happening since then.

Face to Face: Committer's Day

At the Face to Face meeting held on the occasion of the ICMC19 Conference in Vancouver, a novelty was introduced: For the last day of the meeting all committers were invited to participate, either personally or remotely via video conference.

New Committers

Following on from our additions to the committers last year, the OpenSSL Management Committee has now added four new Committers.

OpenSSL 3.0 and FIPS update

As mentioned in a previous blog post, OpenSSL team members met with various representatives of the FIPS sponsor organisations back in September last year to discuss design and planning for the new FIPS module development project.

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.

Celebrating 20 years of OpenSSL

20 years ago, on the 23rd December 1998, the first version of OpenSSL was released. OpenSSL was not the original name planned for the project but it was changed over just a few hours before the site went live. Let’s take a look at some of the early history of OpenSSL as some of the background has not been documented before.

The Holy Hand Grenade of Antioch

The OpenSSL Management Committee has been looking at the versioning scheme that is currently in use. Over the years we’ve received plenty of feedback about the “uniqueness” of this scheme, and it does cause some confusion for some users. We would like to adopt a more typical version numbering approach. 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.

FIPS 140-2: Forward progress

The OpenSSL Management Committee (OMC) on behalf of the OpenSSL Project would like to formally express its thanks to the following organisations for agreeing to sponsor the next FIPS validation effort: Akamai Technologies, Blue Cedar, NetApp, Oracle, VMware.

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 is released

After two years of work we are excited to be releasing our latest version today - OpenSSL 1.1.1. This is also our new Long Term Support (LTS) version and so we are committing to support it for at least five years.

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.

New OMC member and new Committers

We first announced last year the OpenSSL Management Committee and separate Committers groups aimed at enabling greater involvement from the community.

We have now added a new OMC member and two new committers.

New LTS Release

Back around the end of 2014 we posted our release strategy. This was the first time we defined support timelines for our releases, and added the concept of an LTS (long-term support) release. At our OMC meeting earlier this month, we picked our next LTS release. This post walks through that announcement, and tries to explain all the implications of it.

Changing the guiding principles in our Security Policy

“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.

Seeking Last Group of Contributors

The following is a press release that we just put out about how finishing off our relicensing effort. For the impatient, please see https://license.openssl.org/trying-to-find to help us find the last people; we want to change the license with our next release, which is currently in Alpha, and tentatively set for May.

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.

Using TLS1.3 with OpenSSL

Note: This is an outdated version of this blog post. This information is now maintained in a wiki page. See here for the latest version.

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.

Another Face to Face: Email changes and crypto policy

The OpenSSL OMC met last month for a two-day face-to-face meeting in London, and like previous F2F meetings, most of the team was present and we addressed a great many issues. This blog posts talks about some of them, and most of the others will get their own blog posts, or notices, later. Red Hat graciously hosted us for the two days, and both Red Hat and Cryptsoft covered the costs of their employees who attended.

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.

OpenSSL wins the Levchin prize

Today I have had great pleasure in attending the Real World Crypto 2018 conference in Zürich in order to receive the Levchin prize on behalf of the OpenSSL team. 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.

Steve Marquess

Steve Marquess is leaving the OpenSSL project as of the 15th of November 2017. 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!

Steve Henson

For as long as I have been involved in the OpenSSL project there has been one constant presence: Steve Henson. In fact he has been a part of the project since it was founded and he is the number 1 committer of all time (by a wide margin). I recall the first few times I had any dealings with him being somewhat in awe of his encyclopaedic knowledge of OpenSSL and all things crypto.

Seven days and four cities in China

We had been invited to spend time with the open source community in China by one of the developers - Paul Yang - who participates in the OpenSSL project. A number of the team members had communicated via email over the last year and when the suggestion was made there were enough of us willing and interested to visit China for a “tour” to make sense. So the tour was agreed as a good thing and that started the journey that lead to spending a week in China (last week as I write this on the plane on the way back to Australia).

FIPS 140-2: Thanks and Farewell to SafeLogic

We’ve had a change in the stakeholder aspect of this new FIPS 140 validation effort. The original sponsor, SafeLogic, with whom we jump-started this effort a year ago and who has worked with us since then, is taking a well-deserved bow due to a change in circumstances. Supporting this effort has been quite a strain for a relatively small company, but SafeLogic has left us in a fairly good position. Without SafeLogic we wouldn’t have made it this far, and while I don’t anticipate any future SafeLogic involvement with this effort from this point on, I remain enormously grateful to SafeLogic and CEO Ray Potter for taking on such a bold and ambitious venture.

Random thoughts

The next release will include a completely overhauled version of the random number facility, the 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.

FIPS 140-2: And so it begins

It’s been almost a year since plans for a new FIPS 140 validation were first announced. Several factors have led to this long delay. For one, we chose to focus our limited manpower resources on higher priority objectives such as the TLS 1.3 implementation. SafeLogic has also experienced difficulties in obtaining the funding for their intended sponsorship; potential sponsors can contact them directly. With TLS 1.3 now done (pending only a final TLS 1.

Removing some code

This is another update on our effort to re-license the OpenSSL software. Our previous post in March was about the launch of our effort to reach all contributors, with the hope that they would support this change.

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.

New Committers

We announced back in October that we would be changing from a single OpenSSL Project Team to having an OpenSSL management committee and a set of committers which we planned to expand to enable the greater involvement from the community.

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.

Using TLS1.3 with OpenSSL

Note: This is an outdated version of this blog post. This information is now maintained in a wiki page. See here for the latest version.

Licensing Update

The following is a press release that we just released, with the cooperation and financial support of the Core Infrastructure Initiative and the Linux Foundation.

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:

OpenSSL and Threads

This post talks about OpenSSL and threads. In particular, using OpenSSL in multi-threaded applications. It traces through the history, explains what was changed for the 1.1.0 release, and will hopefully provide some guidance to developers.

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.

Project Bylaws

Last October, the OpenSSL Project team had a face to face meeting. We talked about many topics but one of them was that, in recent years, we have seen much more involvement from the community and that we would like to encourage that further. For example, there are a number of people in the community who we know and trust. We would like those people to get involved more and make it easier for them to contribute. We decided to introduce the concept of a “committer” (borrowed from the Apache concept): someone who has the ability to commit code to our source code repository but without necessarily having to become a full team member. This might be seen as a stepping-stone for someone who aspires to full team membership, or simply as an easier way of contributing for those that don’t. Those people could help with our review process (i.e., their reviews would count towards approval) - which might help us keep on top of the github issues and pull request queues.

Face to Face: Roadmap and platform updates

This is another in the series of posts about decisions we made at our face-to-face meeting a couple of weeks ago. 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.

Face to Face: Goodbye RT, hello GitHub

Last week, the OpenSSL dev team had another face-to-face meeting. It was a week of “mosts”: most of the team flew in for most of the week, and most of it was funded by the CII/LF

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.

The SWEET32 issue, CVE-2016-2183

Today, Karthik Bhargavan and Gaetan Leurent from Inria have unveiled a new attack on Triple-DES, SWEET32, Birthday attacks on 64-bit block ciphers in TLS and OpenVPN. It has been assigned CVE-2016-2183.

This post gives a bit of background and describes what OpenSSL is doing. For more details, see their website.

FIPS 140-2: Once more unto the breach

The last post on this topic sounded a skeptical note on the prospects for a new FIPS 140 validated module for OpenSSL 1.1 and beyond. That post noted a rather improbable set of prerequisites for a new validation attempt; ones I thought only a governmental sponsor could meet (as was the case for the five previous open source based validations).

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.

Undefined Pointer Arithmetic

In commits a004e72b9 (1.0.2) and 6f35f6deb (1.0.1) we released a fix for CVE-2016-2177. The fix corrects a common coding idiom present in OpenSSL 1.0.2 and OpenSSL 1.0.1 which actually relies on a usage of pointer arithmetic that is undefined in the C specification. The problem does not exist in master (OpenSSL 1.1.0) which refactored this code some while ago. This usage could give rise to a low severity security issue in certain unusual scenarios. The OpenSSL security policy (https://openssl-library.org/policies/general/security-policy/) states that we publish low severity issues directly to our public repository, and they get rolled up into the next release whenever that happens. The rest of this blog post describes the problem in a little more detail, explains the scenarios where a security issue could arise and why this issue has been rated as low severity.

An OpenSSL user's guide to DROWN

Today, an international group of researchers unveiled DROWN (Decrypting RSA with Obsolete and Weakened eNcryption), aka CVE-2016-0800, a novel cross-protocol attack that uses SSLv2 handshakes to decrypt TLS sessions.

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.

Poly1305 revised

Poly1305 implementations are characterized by several parameters:

radix or base of inputs representation, or how many digits represent the 130-bit value the algorithm operates on;
vectorization factor, or how many input blocks are processed per [loop] iteration and in parallel;
floating-point vs. integer/scalar arithmetic;

Engine Building Lesson 2: An Example MD5 Engine

Coming back after a month and two weeks, it’s time to resume with the next engine lesson, this time building an engine implementing a digest.

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)

Engine building lesson 1: A minimum useless engine

In this lesson, we’re going to explore minimalism, in this case in the form of the most minimal engine possible (without obfuscating it).

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.

Engine school, a path to writing standalone engines

For the longest time, it seems that people have wanted to have their diverse engines bundled with the OpenSSL source, as if there was no other way to build it or distribute it. 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.

New severity level, "Critical"

We’ve just added a new severity level called “critical severity” to our security policy. When we first introduced the policy, over a year ago, we just had three levels, “Low”, “Moderate”, and “High”. So why did we add “Critical” and why are we not using someone else’s standard definitions? After introducing the new policy we started giving everyone a headsup when we were due to release OpenSSL updates that included security fixes.

FIPS 140-2: It's not dead, it's resting

Some of you may have noticed that the upcoming 1.1 release doesn’t include any FIPS support. That omission is not by choice; it was forced on us by circumstances and will hopefully not be permanent. 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.

OpenSSL Security: A Year in Review

Over the last 10 years, OpenSSL has published advisories on over 100 vulnerabilities. Many more were likely silently fixed in the early days, but in the past year our goal has been to establish a clear public record. 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.

New website

We just went live with a new website. The design is based on the style included with Octopress; the new logo and some other important CSS tweaks were contributed by Tony Arcieri. The style is also mobile-friendly, so you can take us with you wherever you go. :) We still need a better “favicon.” 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?

License Agreements and changes are coming

The OpenSSL license is rather unique and idiosyncratic. It reflects views from when its predecessor, SSLeay, started twenty years ago. As a further complication, the original authors were hired by RSA in 1998, and the code forked into two versions: OpenSSL and RSA BSAFE SSL-C. (See Wikipedia for discussion.) I don’t want get into any specific details, and I certainly don’t know them all.

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.

Beyond reformatting: More code cleanup

The OpenSSL source doesn’t look the same as it did a year ago. Matt posted about the big code reformatting. In this post I want review some of the other changes – these rarely affect features, but are more than involved than “just” whitespace.

Logjam, FREAK and upcoming changes in OpenSSL

Today, news broke of Logjam, an attack on TLS connections using Diffie-Hellman ciphersuites. To protect OpenSSL-based clients, we’re increasing the minimum accepted DH key size to 768 bits immediately in the next release, and to 1024 bits soon after. We have also made several other changes to strengthen our cryptographic defaults and have updated our tools and documentation to help servers configure Diffie-Hellman ciphersuites securely - see below for details.

Security Updates

We’ve just released security updates to OpenSSL 0.9.8, 1.0.0, 1.0.1, and 1.0.2.

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.