AESGCM fails on RHEL9 in FIPS mode

[schwabe]

Precondition: Have RHEL9 running in FIPS mode and cryptography 46

Small unit test minimal example:

def test_aes_gcm_encrypt():
        from cryptography.hazmat.primitives.ciphers.aead import AESGCM
        import os
    
        key = os.urandom(16)
        aesgcm = AESGCM(key)
    
        iv = os.urandom(12)
>       encrypted = aesgcm.encrypt(iv, b"I am a test", None)
E       cryptography.exceptions.InternalError: Unknown OpenSSL error. This error is commonly encountered
E                           when another library is not cleaning up the OpenSSL error
E                           stack. If you are using cryptography with another library
E                           that uses OpenSSL try disabling it before reporting a bug.
E                           Otherwise please file an issue at
E                           https://github.com/pyca/cryptography/issues with
E                           information on how to reproduce this. (error:030000BE:digital envelope routines:EVP_CIPHER_CTX_copy:not able to copy ctx:crypto/evp/evp_enc.c:1792:)

This has been test with 46.0.7 but is likely a regression added by 98dfafe. The version 41.0.7 from the Red Hat package python3.12-cryptography does not exhibit this problem.

A possible workaround is to use aesgcm = Cipher(algorithms.AES(key), modes.GCM(iv)).encryptor() instead as that still works.

[schwabe]

After a bit of discussion in #pyca irc channel it looks like the main culprit is that aead.rs uses LazyEvpCipherAead vs EvpCipherAead based on CRYPTOGRAPHY_OPENSSL_320_OR_GREATER but depending on the main OpenSSL version. So if a FIPS module uses a lower version (3.0.7 in this case) than the main OpenSSL version, it selects an implementation that only works with the default provider but not with the fips provider.

[alex]

As discussed on IRC, I think this is a consequence of us using build-time feature detection and that being effectively inaccurate due to OpenSSL allowing (and RHEL choosing to) mixing-and-matching OpenSSL and provider versions.

This is one where if someone comes up with a PR that's appropriately maintainable, I'm happy to review and consider it, but I'm not going to do any work on this myself. And if it's not possible to fix in a reasonable way, that'll just be Yet Another Unfortunate Consequence of OpenSSL's unfortunate design choices: https://cryptography.io/en/latest/statements/state-of-openssl/

[alex]

Additional note: we test against centos-stream 9 in CI, so it'd be interesting to understand why that's fine.

[schwabe]

The reason is that Centos 9 stream does not ship with a certified FIPS module but just with a "random" FIPS module that is built from the version as OpenSSL itself:

[14:22]{1}arne@centos9-fips:~% openssl list -providers
Providers:
  base
    name: OpenSSL Base Provider
    version: 3.5.5
    status: active
  default
    name: OpenSSL Default Provider
    version: 3.5.5
    status: active
  fips
    name: Red Hat Enterprise Linux OpenSSL FIPS Provider
    version: 3.5.5-ab02c3b56688c2b8
    status: active

vs

[14:23]arne@rhel9-fips:~% openssl list -providers
Providers:
  base
    name: OpenSSL Base Provider
    version: 3.5.1
    status: active
  default
    name: OpenSSL Default Provider
    version: 3.5.1
    status: active
  fips
    name: Red Hat Enterprise Linux 9 - OpenSSL FIPS Provider
    version: 3.0.7-395c1a240fbfffd8
    status: active

[abbra]

I added a fix that tries if the newer call works first time and then falls back to old if it doesn't. @schwabe can you try that in your environment?