[转帖]Strong crypto defaults in RHEL 8 and deprecation of weak crypto algorithms

https://access.redhat.com/articles/3642912

Red Hat Enterprise Linux includes several cryptographic components whose security does not remain constant over time. Algorithms such as (cryptographic) hashing and encryption typically have a lifetime after which they are considered either too risky to use or plainly insecure. That means we need to phase out those algorithms from the default settings, or completely disable them if they cannot be used securely at all. While in the past we did not disable algorithms in a consistent way (different applications utilized different policies), today we have a system-wide policy which is followed by all RHEL crypto core components. These policies allow us to consistently handle and deprecate algorithms system-wide. Decisions about policy contents are based on documents like RFC 7457 which gives a list of attacks taking advantage of legacy crypto algorithms.

The following text lists, in detail, the algorithms that are either completely removed or disabled in the different crypto policy levels in RHEL-8. For a high level description of the change see this blog post and this kbase article.

For further details, please see the crypto-policies manual page.

What policies are provided?

Four policies are provided under the names “LEGACY”, “DEFAULT”, “FUTURE” and “FIPS”. They are summarized and described in the table below.

Policy name	Description
LEGACY	This policy ensures maximum compatibility with legacy systems; it is less secure and it includes support for TLS 1.0, TLS 1.1, and SSH2 protocols or later. The algorithms DSA, 3DES, and RC4 are allowed, while RSA and Diffie-Hellman parameters are accepted if larger than 1023-bits.
DEFAULT	The DEFAULT policy is a reasonable default policy for today's standards, aimed for a balance between usability and security. It allows the TLS 1.2 and 1.3 protocols, as well as IKEv2 and SSH2. The RSA and Diffie-Hellman parameters are accepted if larger than 2047-bits.
FUTURE	A conservative security level that is believed to withstand any near-term future attacks. The purpose of the policy is for testing infrastructure and applications for their readiness for future strengthening of requirements. The policy is not supposed to be used for general purpose systems. This level does not allow the use of SHA-1 in signature algorithms. The RSA and Diffie-Hellman parameters are accepted if larger than 3071-bits.
FIPS	A level that conforms to the FIPS140-2 requirements. This policy is used internally by the `fips-mode-setup` tool which can switch the RHEL system into FIPS140 mode.

Removed ciphersuites and protocols

These ciphersuites and protocols are completely removed from the core crypto libraries. They are either not present at all in the sources or their support is disabled during the build so it cannot be used by applications in any way.

DES (since RHEL-7)
All export grade ciphersuites (since RHEL-7)
MD5 in signatures (since RHEL-7)
SSLv2 (since RHEL-7)
SSLv3 (since RHEL-8)
All ECC curves < 224 bits (since RHEL-6)
All binary field ECC curves (since RHEL-6)

Disabled in all policy levels

These ciphersuites and protocols are available but disabled in all crypto policy levels. They can be enabled only by explicit configuration of individual applications.

DH with parameters < 1024 bits
RSA with key size < 1024 bits
Camellia
ARIA
SEED
IDEA
Integrity only ciphersuites
TLS Ciphersuites using SHA-384 HMAC
AES-CCM8
all ECC curves incompatible with TLS 1.3, including secp256k1
IKEv1 (since RHEL-8)

Disabled in DEFAULT policy, but enabled in LEGACY policy

These ciphersuites and protocols are disabled in the DEFAULT crypto policy level. They can be enabled by switching the system crypto policy level to LEGACY.

3DES
RC4
DH with parameters < 2048 bits
RSA with key size < 2048 bits
DSA (all key sizes)
TLSv1.0
TLSv1.1

Disabled in the FIPS policy in addition to the DEFAULT policy

The FIPS policy allows only FIPS approved or allowed algorithms. It must be used when the system is required to be FIPS compliant. It is automatically selected when enabling the system FIPS mode.

SHA1 in digital signatures
RSA key exchange
X25519, X448, Ed25519 and Ed448
Chacha20-Poly1305

Disabled in the FUTURE policy, but enabled in the DEFAULT policy

The FUTURE policy provides additional hardening of the system. It is a conservative security level that is believed to withstand any near-term future attacks. The policy is not supposed to be used for general purpose systems.

CBC mode ciphersuites in TLS
Symmetric ciphers with smaller keys than 256 bits
SHA-1 and SHA-224 signatures in certificates
DH with parameters < 3072 bits
RSA with key size < 3072 bits

Please note that most of the current WWW site certificates use just 2048 bits RSA keys so it will not be possible to connect to most of the public WWW sites with this policy.

Remediation of most common issues missing algorithms and protocol support

Switching to the LEGACY policy can be done by issuing the command update-crypto-policies --set LEGACY from the root account.
DH with small parameters - either switch to the LEGACY policy, or fix the TLS server to provide at least 2048 bit DH parameters, or use ECDH.
SSLv3 - fix the TLS server to provide TLSv1.2 protocol (or at least TLSv1.0 protocol and switch to the LEGACY policy).
3DES, RC4 - either switch to the LEGACY policy or fix the TLS server to provide AES based ciphersuites.
RSA with small keys, DSA - either switch to the LEGACY policy or generate new keys (with at least 2048 bits but preferably more) and certificates for the TLS server.
TLSv1.0, 1.1 - either switch to the LEGACY policy or update the TLS server to provide TLSv1.2 protocol support.
SHA1 in signatures in FIPS mode - regenerate the certificates to use SHA256 based signatures.
Camellia, SEED, or ARIA - if the application configuration allows for modification of the ciphersuite configuration string, follow the documentation of the application to add these ciphersuites to the configuration string. Or remove the symlink to crypto policy configuration of the appropriate crypto library in /etc/crypto-policies/back-ends and replace it with configuration that will include the needed ciphersuite. Note that any modification described above, is unsupported by Red Hat. In the future we intend to provide a method create and use custom policies.
IKEv1 - To opt out from the policy, comment the line including /etc/crypto-policies/back-ends/libreswan.config from /etc/ipsec.conf and add ikev2=never to the libreswan connection configuration.

Product(s)
Red Hat Enterprise Linux

Category
Secure

Article Type
General