Chapter 17. Security
The following chapters contain the most notable changes to security between RHEL 9 and RHEL 10.
ca-certificates trust store moved
The /etc/pki/tls/certs trust store is converted to a different format better optimized for OpenSSL. As a consequence, if you use the files in /etc/pki/tls/certs directly, switch to the /etc/pki/ca-trust/extracted directory, where the same data is stored. For example, software that accesses the trust bundle at /etc/pki/tls/certs/ca-bundle.crt should switch to using /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem instead.
compat-openssl11 is removed
The compatibility library for OpenSSL 1.1, compat-openssl11, has been removed from RHEL 10. OpenSSL 1.1 is no longer maintained upstream and applications that use the OpenSSL TLS toolkit should be migrated to version 3.x.
pkcs11-provider replaces openssl-pkcs11
As a part of the migration from OpenSSL engines to the Providers API, the pkcs11-provider package replaces the openssl-pkcs11 package (engine_pkcs11). The openssl-pkcs11 package is removed from RHEL 10.
DEFAULT cryptographic policy rejects TLS ciphers with RSA key exchange
TLS ciphers that use the RSA key exchange are no longer accepted in the DEFAULT system-wide cryptographic policy in RHEL 10. These ciphers do not provide perfect forward secrecy and are not considered as secure as ciphers that use other key exchanges, for example, the Elliptic-curve Diffie-Hellman (ECDH) key exchange.
This change also reduces the exposure to side-channel attacks because the RSA key exchange uses PKCS #1 v1.5 encryption padding, which can cause vulnerability to timing side-channel attacks.
If you need the RSA key exchange for interoperability with legacy systems, you can re-enable it by using the LEGACY system-wide cryptographic policy or by applying a custom subpolicy.
The LEGACY cryptographic policy disallows SHA-1 signatures in TLS
The LEGACY system-wide cryptographic policy in RHEL 10 no longer allows creating or verifying signatures that use SHA-1 in TLS contexts. Therefore, libraries other than OpenSSL might no longer accept or create any signatures that use SHA-1 regardless of use case. OpenSSL continues to accept signatures that use SHA-1 when not used for TLS if the system is in LEGACY or this functionality is re-enabled with a custom subpolicy.
OpenSSL no longer permits SHA-1 at SECLEVEL=2 in TLS
OpenSSL does not accept the SHA-1 algorithm at SECLEVEL=2 in TLS in RHEL 10. If your scenario requires using TLS 1.0 or 1.1, you must explicitly set SECLEVEL=0 and switch to the LEGACY system-wide cryptographic policy. In the LEGACY policy, applications that use SHA-1 in signatures outside of TLS will continue to work.
Switching to LEGACY policy does not enable support for SHA-1 in TLS connections
You can control support for SHA-1 signatures either by the @SECLEVEL setting specified in the default cipher string or the rh-allow-sha1-signatures property. Support for SHA-1 in the TLS context is enabled by setting @SECLEVEL=0. However, this setting also allows other insecure algorithms.
You can override the SECLEVEL setting by specifying the rh-allow-sha1-signatures property in the evp_properties section. By default and when unspecified in the configuration file, evp_properties is set to no. The system-wide cryptographic policies set the property to yes after you switch to the LEGACY policy.
Therefore, to enable support for SHA-1 in contexts outside TLS, you can switch the system to the LEGACY cryptographic policy. To enable SHA-1 in TLS, you must switch the system to LEGACY and use a cipher string that sets @SECLEVEL=0 either by defining a custom cryptographic policy or setting this for your application in OpenSSL.
/etc/system-fips removed
Support for indicating FIPS mode through the /etc/system-fips file has been removed from RHEL. To install RHEL in FIPS mode, add the fips=1 parameter to the kernel command line during the system installation. You can check whether RHEL operates in FIPS mode by displaying the /proc/sys/crypto/fips_enabled file.
17.1. Security compliance changes
Installation hardening with OSCAP Anaconda Addon removed
The oscap-anaconda-addon package has been removed. As a consequence, the RHEL 10 installer no longer provides the Security Policy spoke and installation hardening. RHEL 10 introduces a more flexible and customizable approach to hardening systems by using Anaconda and Kickstart in addition to the already existing Image Builder option. For more information, see Creating pre-hardened images with RHEL image builder OpenSCAP integration.
OpenSCAP
The new version 1.4.x of the OpenSCAP scanner is provided in RHEL 10. The most important changes are the following:
-
The
openscappackage no longer provides theopenscap-develsubpackage for thelibopenscaplibrary, which is now an internal library without public API and any guarantee for backward compatibility. Theopenscappackage is provided with no guarantee of ABI and API compatibility. The following
dssubmodules that provide data stream composing functions have been removed from theoscaptool:-
sds-compose -
sds-add -
sds-split -
rds-create -
rds-split
-
The following incomplete modules have been removed:
-
cve -
cvss -
cvrf
-
The following deprecated command-line options have been removed:
-
--template -
--oval-template -
--sce-template -
--skip-validis removed and is replaced by--skip-validation
-
- New Kickstart remediation type was added.
-
The
autotailortool now can produce XCCDF tailoring files based on JSON Tailoring.
SCAP Workbench
The scap-workbench package with the SCAP Workbench GUI utility has been removed. As alternatives, you can use the oscap and autotailor command-line tools or Red Hat Insights for both tailoring and scanning. For more information, see Managing SCAP security policies in the Insights for RHEL compliance service.
SCAP Security Guide
The scap-security-guide package does not contain the following profiles:
- Protection Profile for General Purpose Operating Systems (OSPP)
- Centro Criptológico Nacional (CCN) - Basic
- Centro Criptológico Nacional (CCN) - Intermediate
For the complete list of profiles supported in RHEL 10, see SCAP security profiles supported in RHEL 10.
