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.
After extensive feedback from our communities, OpenSSL is pleased to announce that we have formally adopted the Mission and Values Statement, and will now be aligning our activities to support these.
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.
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.
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.