Review OpenSSL 3.1 End of Support

Hi Craig,

Maybe the ask is to see if OpenSSL will extend the 3.1 support date till September of 2026 when the FIPS 140-2 or OpenSSL 3.0 module goes out of compliance or until the OpenSSL 3.5 release for which FIPS 140-3 certification is planned gets submitted to the CMVP? That could allow consumers of the FIPS module to have a FIPS story until 3.5 gets submitted? Does this seem like a reasonable ask?

Can't the FP 3.1.2 be used with OpenSSL3.5 thereby enabling FIPS 140-3 on the LTS branch of OpenSSL3.5? Just wondering if I am missing something... I usually am :)

Or are you just talking about the FIPS Provider CVE fixes inside the boundary? Since it just got the cert I don't think the EOL of OpenSSL3.1 means the EOL of the FP 3.1.2 but clarity on that would be helpful. It wouldn't make a lot of sense to finally get a FIPS cert and not support the FP IMO.

To be clear I am suggesting OpenSSL extend 3.1 support until the 3.5 FIPS provider is available; This will ensure that the 140-3 validated FIPS provider continues to receive CVE fix until the replacement 3.5 provider is available for those who wish to use a 140-3 validated module.

Those who are happily consuming the 3.0 FIPS provider (140-2) may continue to consume that with another supported OpenSSL release if they want performance/feature upgrades made since 3.0s release.

The Corporation BAC call on the 25th included a comment to the effect that the 3.1 FIPS provider will be supported until it is sun setted (most likely five years from submission) but that 3.1 itself won't be. That's workable because, as mentioned, the 3.1 FIPS provider will work just fine with 3.5 and it will continue to do so. Details about how to use a FIPS provider with a different OpenSSL version are included in the documentation.

Hi, a few questions...

Isn't OpenSSL 3.1 needed to build FP 3.1? In other words FP 3.1 isn't a self contained entity. Isn't the case that CVE fixes affecting FP 3.1 has to be delivered in OpenSSL 3.1?

@Norman Ashley Disclaimer: I am not a compliance expert and I am not your compliance expert. Commentary is about technical feasibility, not necessarily what compliance/regulators will want for your software environments.

I read the comment as, and OpenSSL Members can confirm, security issues (CVEs) which impact the FIPS module will be back-ported to the 3.1 code base. - To be documented

One can then pull the code for Openssl 3.1 which can build the FIPS module without known CVEs. Businesses who wish to, or are told by compliance/regulators that they must use a FIPS 140-3 module, may continue using the 3.1 module, and use that module with another supported OpenSSL release. Businesses will need to work with their compliance contacts to determine if they should/must take the security fixes or migrate to other releases.

There will be performance tradeoffs, but in my mind if a Business needs FIPS 140-3 validated cryptography instead of 140-2, then you may build OpenSSL 3.1 w/ the FIPS module, store the 3.1 module to replace the module built with another selected OpenSSL 3.x version as your base provider and executables, e.g. OpenSSL 3.5.

Norman/Craig

Just want to give you some (hopefully) detailed insight into how FIPS code is managed within openssl, so that you can align that with how FIPS certification is handled, in an effort to give you some better understanding of the situation here.

Branching/Tagging Strategy/background

openssl releases are managed in a per-branch stragegy. That is to say, when we release the alpha version of a given major/minor relelease, we create a unique branch for that release, rooted at the latest commit of the master branch of the repository. That is to say, openssl-3.1 is its own branch, as is openssl-3.2, openssl-3.3, openssl-3.4, openssl-3.5, soon to be openssl-4.0. Note that these branches are named with a given major and minor version number.

When a release is produced, that release is tagged with the requisite patch level of that release (following semantic version rules). i.e. there is a tag for release openssl-3.0.0, openssl 3.0.1, etc. Visually the branches/tags of the tree look like this:

https://docs.google.com/drawings/d/1MWCwlYrsu3ITctbvPrUv_bsPR-QU6AWXmNHpTwfHd6s/edit?usp=sharing

So, each major/minor release pair has a branch, and each specific release has a tag

As we develop code, if a backport for a fix is required, we apply it to the required branches, and when we release a new patch level update for that branch it gets a new tag. This includes all fixes, including those which are CVE-relelvant, either to the core library or the fips provider

Understanding the relation to FIPS certification

Some of our Releases are FIPS certified. For instance, We have a FIPS-140-2 certification for our 3.0.8 and 3.0.9 releases, as well as a FIPS-140-3 certification for our 3.1.2 release. Note those are for specific releases. That is to say, there is no provision for saying that the 3.3.0 release is "close enough" to the 3.1.2 release to still be FIPS compilant. If you want to be FIPS compliant, you must use the 3.0.8, 3.0.9 or 3.1.2 release (dependent on which FIPS certification you want to claim compliance with)

Allowing for the use of updated openssl libraries with compliant providers

OpenSSL guarantees binary compatibility with the fips provider from any release against any other openssl release. That is to say if you want to use the fips provider (codified as the built fips.so module) from a FIPS certified release with a later release of openssl (codified as the libcrypto.so and libssl.so modules). So for example, say you want to leverage the latest features from openssl-3.5.0 while still remaining FIPS compliant. You can do that by building openssl-3.5.0, then building openssl-3.1.2, and simply copying the fips.so module from your openssl-3.1.2 tree into the openssl-3.5.0 tree. We provide instructions on how to do this in each release. This allows for end users to pick up fixes for various bugs/cve's/etc while still remaining FIPS compliant.

Understanding how we handle CVE's within the FIPS provider.

As Norman alluded to, sometimes it may occur that a given CVE may be encountered which modifies code within the FIPS provider, and the question becomes "what do we do about that?". As noted above, FIPS compliance is attached to a specific openssl release, and as such, remaining FIPS compliant for an end user implies that they cannot move to a later patch release to mitigate a CVE. They must remain on that certified release, regardless of the impact of any newly discovered CVE within the fips provider

There is however a way out of this situation. FIPS allows for an update process (in FIPS-140-3 its called an UPDT process, in 140-2 I believe its called the scenario 3A process). In this process we would work with our lab to indicate that we are addressing a CVE, and the changes to the FIPS provider are very limited. Our lab would then work with NIST in an accelerated review process to validate the new code (i.e. much more quickly than the full validation process). The outcome of that process would be a new certificate, issued from NIST referencing the new openssl release as being FIPS certified, which we would then publish for availability to our end users, how could then update to that release, providing mitigation for the relevant CVE, without sacrificing FIPS validation.

Closing thoughts

I should note here that, nominally CVE's relevant to the fips provider are only considered for re-certification at (I think) medium and higher severity). Low severity items are not currently considered for re-certification. To the best of my knoweldge we have not encountered a high severity CVE within the bounds of our FIPS provider, and so have not had to go through this process to date.

Hope that helps.

Neil

@Neil Horman Thanks for the detailed response. I feel like I understand all of that; branches and tags separating trains and releases, and FIPS certificates are a point in time validated of the specific cryptographic module, in OpenSSL terms fips provider. The item that I am not seeing concrete documentation on is how End of Support (EoS) is handled.

3.1 is now EoS, to me that means there is no support provided on that train, e.g. one would not expect code fixes of any type committed to the public branch and no new publicly tagged releases. However, it is suggested that OpenSSL intends to ensure CVE fixes which impact the 3.1 FIPS provider will continue to be committed...I would like to see a clear document on how OpenSSL sees the public maintenance of the FIPS provider in a EoS branch/train.

For clarity, I am fully aware that FIPS validity is connected to the specific tested version. While the specifics of a company's regulatory compliance is a concern, I am talking about the security implications here and leave it to individual company's and their compliance contacts/contracts to guide and balance the need for picking up CVE fixes within the FIPS module (provider).

@Neil Horman Thank you for this response. I did want to clarify on reason why support for the 3.1 branch specifically is important for large businesses:

One big driver for using FIPS-140 validated modules is FedRAMP. The FedRAMP Policy for Cryptographic Module Selection recognizes the tension between the use of validated modules and patching security issues. It therefore explicitly directs CSPs to prefer using patched modules, even if not validated. (This is reinforced throughout the policy - e.g. "CSPs shall determine if updating to a newer version of the software, whether or not its cryptographic modules are FIPS validated, would eliminate the vulnerabilities; if it would, CSPs shall promptly update if that is feasible.")

FedRAMP further goes on to distinguish "modules that are derived from an update stream of an existing validated module" from those that are not. That is why it is so important to consumers of the 3.1 module to have support on the 3.1 branch.