Bug 2070977

I'm already working on this.

Acceptance Criteria:
 - when rh-allow-sha1-signatures is not set the creation and verification of SHA-1 signatures succeeds
 - when rh-allow-sha1-signatures is set to "no", creation and verification of SHA-1 signatures fails
 - In TLS, SHA-1 signature support in the signature_algorithms extension in ClientHello and CertificateRequest is advertised when rh-allow-sha1-signatures is "yes" and the current SECLEVEL is lower than 2
 - In TLS, SHA-1 signature support in the signature_algorithms extension in ClientHello and CertificateRequest is not advertised when rh-allow-sha1-signatures is unset and the current SECLEVEL is equal to 2
 - openssl1.1 does not fail when rh-allow-sha1-signatures is set (but does not actually support the option otherwise)

For some context, our plans outside of F36 and F37 for this are:

SHA1 behavior in:
------------------------------------------------------------------------------------------
|     | r-a-s-s default | LEGACY(SECLEVEL=1) | DEFAULT(SECLEVEL=2) | FUTURE (SECLEVEL=3) |
==========================================================================================
| F35 |     N/A         |     Allow Always   |   Disallow in TLS   |   Disallow in TLS   |
------------------------------------------------------------------------------------------
| F36 |  r-a-s-s=y      |     Allow Always   |   Disallow in TLS   |   Disallow in TLS   |
------------------------------------------------------------------------------------------
| F37 |  r-a-s-s=y      |     Allow Always   |   Disallow in TLS   |   Disallow Always   |
|     |                 |                    |                     |    r-a-s-s -> n     |
------------------------------------------------------------------------------------------
| F38 |            rawhide as-F39, then revert to as-F37 before release                  |
------------------------------------------------------------------------------------------
| F39 |  r-a-s-s=n      |   Disallow in TLS  |   Disallow Always   |   Disallow Always   |
|     |                 |    r-a-s-s -> y    |                     |                     |
------------------------------------------------------------------------------------------

openssl1.1 seems to ignore the unknown option. I tested this with python3-m2crypto-0.38.0-2.fc35 on F36:

$ cat sign_rsa.py
#!/usr/bin/python3

import sys
from pathlib import Path
from M2Crypto import BIO, RSA, EVP

bio = BIO.MemoryBuffer(Path(sys.argv[1]).read_bytes())
rsa = RSA.load_key_bio(bio)
key = EVP.PKey()
key.assign_rsa(rsa)

payload = Path(sys.argv[2]).read_bytes()
key.digest_sign_init()
key.digest_sign_update(payload)
signature = key.digest_sign_final()

Path(sys.argv[3]).write_bytes(signature)
$ ./sign_rsa.py key.pem original-ks.cfg original-ks.cfg.sha1.sig
$ echo $?
0
$ grep -E '(alg_section|evp_properties|rh-allow-sha1-signatures)' /etc/pki/tls/openssl.cnf
alg_section = evp_properties
[evp_properties]
rh-allow-sha1-signatures = no

The config files were actually read by openssl 1.1:

$ strace -e trace=openat ./sign_rsa.py key.pem original-ks.cfg original-ks.cfg.sha1.sig |& grep -E '/etc/(pki|crypto-policies)'
openat(AT_FDCWD, "/etc/pki/tls/openssl.cnf", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/crypto-policies/back-ends/opensslcnf.config", O_RDONLY) = 4
openat(AT_FDCWD, "/etc/pki/tls/openssl.cnf", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/crypto-policies/back-ends/opensslcnf.config", O_RDONLY) = 4

And m2crypto does link against openssl 1.1:

$ dnf repoquery -l python3-m2crypto | grep _m2crypto
/usr/lib64/python3.10/site-packages/M2Crypto/_m2crypto.cpython-310-x86_64-linux-gnu.so
$ ldd /usr/lib64/python3.10/site-packages/M2Crypto/_m2crypto.cpython-310-x86_64-linux-gnu.so | grep -E 'lib(ssl|crypto)'
        libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fe38a3a0000)
        libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fe38a0b3000)

The generated signature is valid:

$ openssl dgst -sha1 -binary -out original-ks.cfg.sha1 original-ks.cfg
$ openssl pkeyutl -inkey key.pem -verify -sigfile original-ks.cfg.sha1.sig -in original-ks.cfg.sha1 -pkeyopt digest:sha1
Signature Verified Successfully

With a mockbuild of 3.0.2-2.fc37 on rawhide:

SHA1 support:

$ grep -E '(alg_section|evp_properties|rh-allow-sha1-signatures)' /etc/pki/tls/openssl.cnf
alg_section = evp_properties
[evp_properties]
#rh-allow-sha1-signatures = yes
$ openssl dgst -sha1 -binary -out original-ks.cfg.sha1 original-ks.cfg
$ openssl pkeyutl -inkey localhost.key -sign -in original-ks.cfg.sha1 -out original-ks.cfg.sha1.sig -pkeyopt digest:sha1
$ openssl pkeyutl -inkey localhost.key -verify -sigfile original-ks.cfg.sha1.sig -in original-ks.cfg.sha1 -pkeyopt digest:sha1
Signature Verified Successfully

SHA1 disabled:

$ grep -E '(alg_section|evp_properties|rh-allow-sha1-signatures)' /etc/pki/tls/openssl.cnf
alg_section = evp_properties
[evp_properties]
rh-allow-sha1-signatures = no
$ openssl dgst -sha1 -binary -out original-ks.cfg.sha1 original-ks.cfg
$ openssl pkeyutl -inkey localhost.key -sign -in original-ks.cfg.sha1 -out original-ks.cfg.sha1.sig -pkeyopt digest:sha1
pkeyutl: Can't set parameter "digest:sha1":
C0915DFD797F0000:error:1C8000AE:Provider routines:rsa_setup_md:digest not allowed:providers/implementations/signature/rsa_sig.c:312:digest=sha1
$ openssl pkeyutl -inkey localhost.key -verify -sigfile original-ks.cfg.sha1.sig -in original-ks.cfg.sha1 -pkeyopt digest:sha1
pkeyutl: Can't set parameter "digest:sha1":
C05184CDF57F0000:error:1C8000AE:Provider routines:rsa_setup_md:digest not allowed:providers/implementations/signature/rsa_sig.c:312:digest=sha1

Created attachment 1871457 [details]
Test script for TLS

Created attachment 1871458 [details]
sign_rsa.py from comment 3

FEDORA-2022-52b9bc6268 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-52b9bc6268

FEDORA-2022-52b9bc6268 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

See also https://bodhi.fedoraproject.org/updates/FEDORA-2022-d906a1fd24 for f36.