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