Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2208724

Summary: SSL_CTX_new/SSL_new adding spurious errors to the stack in FIPS mode
Product: Red Hat Enterprise Linux 9 Reporter: Paul Kehrer <paul.l.kehrer>
Component: opensslAssignee: Dmitry Belyavskiy <dbelyavs>
Status: CLOSED WORKSFORME QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: CentOS StreamCC: alex.gaynor, asosedki, bstinson, cllang, jwboyer, shebburn
Target Milestone: rcKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-23 11:01:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Paul Kehrer 2023-05-20 02:18:26 UTC
Description of problem:
When compiling the following sample code on a centos9 image with /etc/system-fips present an assertion failure occurs due to an error being added to the stack even though the context is successfully returned

```
int main(void) {
	OSSL_PROVIDER *base = OSSL_PROVIDER_load(NULL, "base");
        assert(base != NULL);
	OSSL_PROVIDER *def = OSSL_PROVIDER_load(NULL, "default");
        assert(def != NULL);
        OSSL_PROVIDER *fips = OSSL_PROVIDER_load(NULL, "fips");
        assert(fips != NULL);
        int res = EVP_default_properties_enable_fips(NULL, 1);
	assert(res == 1);
	// The same issue occurs with SSL_new
	SSL_CTX *ctx = SSL_CTX_new(TLS_method());
	assert(ctx != NULL);
	assert(ERR_get_error() == 0);
}
```

This error does not occur without FIPS enabled or in 3.0.7-6.

Version-Release number of selected component (if applicable):
3.0.7-17 (3.0.7-6 unaffected)

How reproducible:
Always

Expected results:
No error

Additional info:

Comment 1 Paul Kehrer 2023-05-20 02:22:27 UTC
This can be quickly replicated using containers we've built for our CI

ghcr.io/pyca/cryptography-runner-centos-stream9-fips@sha256:ac167c676ee3d11f839caf73dc2e0af6f6ee7dc705bc110a625af1b211f00b47 - this image was built three days ago via our automated systems, contains 3.0.7-6, and does not have an issue with the code above.

ghcr.io/pyca/cryptography-runner-centos-stream9-fips@sha256:fd92acad85377e42930015b342975eb204151cf1a45a176a82810dd8079ef5f6 - this image was built a few hours ago, contains 3.0.7-17, and will fail.

Comment 2 Paul Kehrer 2023-05-20 02:24:34 UTC
That code should, of course, have some includes

#include <assert.h>
#include <openssl/provider.h>
#include <openssl/ssl.h>
#include <openssl/err.h>

int main(void) {
	OSSL_PROVIDER *base = OSSL_PROVIDER_load(NULL, "base");
        assert(base != NULL);
	OSSL_PROVIDER *def = OSSL_PROVIDER_load(NULL, "default");
        assert(def != NULL);
        OSSL_PROVIDER *fips = OSSL_PROVIDER_load(NULL, "fips");
        assert(fips != NULL);
        int res = EVP_default_properties_enable_fips(NULL, 1);
	assert(res == 1);
	// The same issue occurs with SSL_new
	SSL_CTX *ctx = SSL_CTX_new(TLS_method());
	assert(ctx != NULL);
	assert(ERR_get_error() == 0);
}

Comment 3 Clemens Lang 2023-05-22 08:55:34 UTC
The presence of `/etc/system-fips` does nothing on CentOS 9 stream.

The actual error message on the stack is

[root@85d90b9f84b5 /]# ./test
80BBD400697F0000:error:0A080106:SSL routines:gid_cb:passed invalid argument:ssl/t1_lib.c:731:group 'X25519' cannot be set
80BBD400697F0000:error:0A000180:SSL routines:ssl_do_config:bad value:ssl/ssl_mcnf.c:77:section=system_default, cmd=Groups, arg=X25519:X448:secp256r1:secp384r1:secp521r1:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192

I'm assuming that's related to the recent changes in crypto-policies on brainpool curves.
Cc+=Alex, Sahana, any idea what's going on here?

Comment 4 Alexander Sosedkin 2023-05-22 09:15:48 UTC
Indeed, crypto-policies now defines `Groups` in `/etc/crypto-policies/back-ends/opensslcnf.config`.
Having X25519 there is indicative of not having FIPS crypto-policy applied.

Now what can we do about it, make openssl ignore it in FIPS mode?

Comment 5 Clemens Lang 2023-05-22 09:18:44 UTC
Ah, so that's actually a misconfiguration then. The container should have run `update-crypto-policies --set FIPS`, and to fully enable FIPS mode, it should offer a '1' to be read from `/proc/sys/crypto/fips_enabled`. Typically, that is done by running the host in FIPS mode.

Since I assume you just need this for testing, you may want to bind-mount a file that contains '1' over this path.

That's also why I couldn't reproduce this on a RHEL 9.2 compose in FIPS mode, because that has the FIPS crypto-policy enabled.

Comment 6 Paul Kehrer 2023-05-23 10:44:29 UTC
Thanks for the information folks! I've updated our container build system to invoke the right incantation for CentOS 9 Stream FIPS and now all our tests are passing.

It'd be nice if there was a better error msg here, but...OpenSSL.

I consider this resolved, thanks again!

Comment 7 Clemens Lang 2023-05-23 11:01:40 UTC
Yeah, we all wish the error messages were better :(

You could try running `fips-mode-setup --check` to verify that the system is correctly switched to FIPS mode.