Blog

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

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 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. Therefore, no new feature PRs will be accepted into the 3.2 branch after this.

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.

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.

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.

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

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

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

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.