Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 3. Using system-wide cryptographic policies
The system-wide cryptographic policies is a system component that configures the core cryptographic subsystems, covering the TLS, IPsec, SSH, DNSSec, and Kerberos protocols. It provides a small set of policies, which the administrator can select.
3.1. System-wide cryptographic policies
When a system-wide policy is set up, applications in RHEL follow it and refuse to use algorithms and protocols that do not meet the policy, unless you explicitly request the application to do so. That is, the policy applies to the default behavior of applications when running with the system-provided configuration but you can override it if required.
RHEL 8 contains the following predefined policies:
DEFAULT
- The default system-wide cryptographic policy level offers secure settings for current threat models. It allows the TLS 1.2 and 1.3 protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 2048 bits long.
LEGACY
-
Ensures maximum compatibility with Red Hat Enterprise Linux 5 and earlier; it is less secure due to an increased attack surface. In addition to the
DEFAULT
level algorithms and protocols, it includes support for the TLS 1.0 and 1.1 protocols. The algorithms DSA, 3DES, and RC4 are allowed, while RSA keys and Diffie-Hellman parameters are accepted if they are at least 1023 bits long. FUTURE
A stricter forward-looking security level intended for testing a possible future policy. This policy does not allow the use of SHA-1 in signature algorithms. It allows the TLS 1.2 and 1.3 protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 3072 bits long. If your system communicates on the public internet, you might face interoperability problems.
ImportantBecause a cryptographic key used by a certificate on the Customer Portal API does not meet the requirements by the
FUTURE
system-wide cryptographic policy, theredhat-support-tool
utility does not work with this policy level at the moment.To work around this problem, use the
DEFAULT
cryptographic policy while connecting to the Customer Portal API.FIPS
Conforms with the FIPS 140 requirements. The
fips-mode-setup
tool, which switches the RHEL system into FIPS mode, uses this policy internally. Switching to theFIPS
policy does not guarantee compliance with the FIPS 140 standard. You also must re-generate all cryptographic keys after you set the system to FIPS mode. This is not possible in many scenarios.RHEL also provides the
FIPS:OSPP
system-wide subpolicy, which contains further restrictions for cryptographic algorithms required by the Common Criteria (CC) certification. The system becomes less interoperable after you set this subpolicy. For example, you cannot use RSA and DH keys shorter than 3072 bits, additional SSH algorithms, and several TLS groups. SettingFIPS:OSPP
also prevents connecting to Red Hat Content Delivery Network (CDN) structure. Furthermore, you cannot integrate Active Directory (AD) into the IdM deployments that useFIPS:OSPP
, communication between RHEL hosts usingFIPS:OSPP
and AD domains might not work, or some AD accounts might not be able to authenticate.NoteYour system is not CC-compliant after you set the
FIPS:OSPP
cryptographic subpolicy. The only correct way to make your RHEL system compliant with the CC standard is by following the guidance provided in thecc-config
package. See the Common Criteria section in the Compliance Activities and Government Standards Knowledgebase article for a list of certified RHEL versions, validation reports, and links to CC guides.
Red Hat continuously adjusts all policy levels so that all libraries provide secure defaults, except when using the LEGACY
policy. Even though the LEGACY
profile does not provide secure defaults, it does not include any algorithms that are easily exploitable. As such, the set of enabled algorithms or acceptable key sizes in any provided policy may change during the lifetime of Red Hat Enterprise Linux.
Such changes reflect new security standards and new security research. If you must ensure interoperability with a specific system for the whole lifetime of Red Hat Enterprise Linux, you should opt-out from the system-wide cryptographic policies for components that interact with that system or re-enable specific algorithms using custom cryptographic policies.
The specific algorithms and ciphers described as allowed in the policy levels are available only if an application supports them:
LEGACY | DEFAULT | FIPS | FUTURE | |
---|---|---|---|---|
IKEv1 | no | no | no | no |
3DES | yes | no | no | no |
RC4 | yes | no | no | no |
DH | min. 1024-bit | min. 2048-bit | min. 2048-bit[a] | min. 3072-bit |
RSA | min. 1024-bit | min. 2048-bit | min. 2048-bit | min. 3072-bit |
DSA | yes | no | no | no |
TLS v1.0 | yes | no | no | no |
TLS v1.1 | yes | no | no | no |
SHA-1 in digital signatures | yes | yes | no | no |
CBC mode ciphers | yes | yes | yes | no[b] |
Symmetric ciphers with keys < 256 bits | yes | yes | yes | no |
SHA-1 and SHA-224 signatures in certificates | yes | yes | yes | no |
[a]
You can use only Diffie-Hellman groups defined in RFC 7919 and RFC 3526.
[b]
CBC ciphers are disabled for TLS. In a non-TLS scenario, AES-128-CBC is disabled but AES-256-CBC is enabled. To disable also AES-256-CBC , apply a custom subpolicy.
|
Additional resources
-
crypto-policies(7)
andupdate-crypto-policies(8)
man pages on your system
3.2. Changing the system-wide cryptographic policy
You can change the system-wide cryptographic policy on your system by using the update-crypto-policies
tool and restarting your system.
Prerequisites
- You have root privileges on the system.
Procedure
Optional: Display the current cryptographic policy:
$ update-crypto-policies --show DEFAULT
Set the new cryptographic policy:
# update-crypto-policies --set <POLICY> <POLICY>
Replace
<POLICY>
with the policy or subpolicy you want to set, for exampleFUTURE
,LEGACY
orFIPS:OSPP
.Restart the system:
# reboot
Verification
Display the current cryptographic policy:
$ update-crypto-policies --show
<POLICY>
Additional resources
- For more information on system-wide cryptographic policies, see System-wide cryptographic policies
3.3. Switching the system-wide cryptographic policy to mode compatible with earlier releases
The default system-wide cryptographic policy in Red Hat Enterprise Linux 8 does not allow communication using older, insecure protocols. For environments that require to be compatible with Red Hat Enterprise Linux 6 and in some cases also with earlier releases, the less secure LEGACY
policy level is available.
Switching to the LEGACY
policy level results in a less secure system and applications.
Procedure
To switch the system-wide cryptographic policy to the
LEGACY
level, enter the following command asroot
:# update-crypto-policies --set LEGACY Setting system policy to LEGACY
Additional resources
-
For the list of available cryptographic policy levels, see the
update-crypto-policies(8)
man page on your system. -
For defining custom cryptographic policies, see the
Custom Policies
section in theupdate-crypto-policies(8)
man page and theCrypto Policy Definition Format
section in thecrypto-policies(7)
man page on your system.
3.4. Setting up system-wide cryptographic policies in the web console
You can set one of system-wide cryptographic policies and subpolicies directly in the RHEL web console interface. Besides the four predefined system-wide cryptographic policies, you can also apply the following combinations of policies and subpolicies through the graphical interface now:
DEFAULT:SHA1
-
The
DEFAULT
policy with theSHA-1
algorithm enabled. LEGACY:AD-SUPPORT
-
The
LEGACY
policy with less secure settings that improve interoperability for Active Directory services. FIPS:OSPP
-
The
FIPS
policy with further restrictions required by the Common Criteria for Information Technology Security Evaluation standard.
Because the FIPS:OSPP
system-wide subpolicy contains further restrictions for cryptographic algorithms required by the Common Criteria (CC) certification, the system is less interoperable after you set it. For example, you cannot use RSA and DH keys shorter than 3072 bits, additional SSH algorithms, and several TLS groups. Setting FIPS:OSPP
also prevents connecting to Red Hat Content Delivery Network (CDN) structure. Furthermore, you cannot integrate Active Directory (AD) into the IdM deployments that use FIPS:OSPP
, communication between RHEL hosts using FIPS:OSPP
and AD domains might not work, or some AD accounts might not be able to authenticate.
Note that your system is not CC-compliant after you set the FIPS:OSPP
cryptographic subpolicy. The only correct way to make your RHEL system compliant with the CC standard is by following the guidance provided in the cc-config
package. See the Common Criteria section in the Compliance Activities and Government Standards Knowledgebase article for a list of certified RHEL versions, validation reports, and links to CC guides hosted at the National Information Assurance Partnership (NIAP) website.
Prerequisites
You have installed the RHEL 8 web console.
For instructions, see Installing and enabling the web console.
-
You have
root
privileges or permissions to enter administrative commands withsudo
.
Procedure
Log in to the RHEL 8 web console.
For details, see Logging in to the web console.
In the Configuration card of the Overview page, click your current policy value next to Crypto policy.
In the Change crypto policy dialog window, click on the policy you want to start using on your system.
- Click the button.
Verification
After the restart, log back in to web console, and check that the Crypto policy value corresponds to the one you selected.
Alternatively, you can enter the
update-crypto-policies --show
command to display the current system-wide cryptographic policy in your terminal.
3.5. Excluding an application from following system-wide crypto policies
You can customize cryptographic settings used by your application preferably by configuring supported cipher suites and protocols directly in the application.
You can also remove a symlink related to your application from the /etc/crypto-policies/back-ends
directory and replace it with your customized cryptographic settings. This configuration prevents the use of system-wide cryptographic policies for applications that use the excluded back end. Furthermore, this modification is not supported by Red Hat.
3.5.1. Examples of opting out of system-wide crypto policies
wget
To customize cryptographic settings used by the wget
network downloader, use --secure-protocol
and --ciphers
options. For example:
$ wget --secure-protocol=TLSv1_1 --ciphers="SECURE128" https://example.com
See the HTTPS (SSL/TLS) Options section of the wget(1)
man page for more information.
curl
To specify ciphers used by the curl
tool, use the --ciphers
option and provide a colon-separated list of ciphers as a value. For example:
$ curl https://example.com --ciphers '@SECLEVEL=0:DES-CBC3-SHA:RSA-DES-CBC3-SHA'
See the curl(1)
man page for more information.
Firefox
Even though you cannot opt out of system-wide cryptographic policies in the Firefox
web browser, you can further restrict supported ciphers and TLS versions in Firefox’s Configuration Editor. Type about:config
in the address bar and change the value of the security.tls.version.min
option as required. Setting security.tls.version.min
to 1
allows TLS 1.0 as the minimum required, security.tls.version.min 2
enables TLS 1.1, and so on.
OpenSSH
To opt out of the system-wide cryptographic policies for your OpenSSH server, uncomment the line with the CRYPTO_POLICY=
variable in the /etc/sysconfig/sshd
file. After this change, values that you specify in the Ciphers
, MACs
, KexAlgoritms
, and GSSAPIKexAlgorithms
sections in the /etc/ssh/sshd_config
file are not overridden.
See the sshd_config(5)
man page for more information.
To opt out of system-wide cryptographic policies for your OpenSSH client, perform one of the following tasks:
-
For a given user, override the global
ssh_config
with a user-specific configuration in the~/.ssh/config
file. -
For the entire system, specify the cryptographic policy in a drop-in configuration file located in the
/etc/ssh/ssh_config.d/
directory, with a two-digit number prefix smaller than 5, so that it lexicographically precedes the05-redhat.conf
file, and with a.conf
suffix, for example,04-crypto-policy-override.conf
.
See the ssh_config(5)
man page for more information.
Libreswan
See the Configuring IPsec connections that opt out of the system-wide crypto policies in the Securing networks document for detailed information.
Additional resources
-
update-crypto-policies(8)
man page on your system
3.6. Customizing system-wide cryptographic policies with subpolicies
Use this procedure to adjust the set of enabled cryptographic algorithms or protocols.
You can either apply custom subpolicies on top of an existing system-wide cryptographic policy or define such a policy from scratch.
The concept of scoped policies allows enabling different sets of algorithms for different back ends. You can limit each configuration directive to specific protocols, libraries, or services.
Furthermore, directives can use asterisks for specifying multiple values using wildcards.
The /etc/crypto-policies/state/CURRENT.pol
file lists all settings in the currently applied system-wide cryptographic policy after wildcard expansion. To make your cryptographic policy more strict, consider using values listed in the /usr/share/crypto-policies/policies/FUTURE.pol
file.
You can find example subpolicies in the /usr/share/crypto-policies/policies/modules/
directory. The subpolicy files in this directory contain also descriptions in lines that are commented out.
Customization of system-wide cryptographic policies is available from RHEL 8.2. You can use the concept of scoped policies and the option of using wildcards in RHEL 8.5 and newer.
Procedure
Checkout to the
/etc/crypto-policies/policies/modules/
directory:# cd /etc/crypto-policies/policies/modules/
Create subpolicies for your adjustments, for example:
# touch MYCRYPTO-1.pmod # touch SCOPES-AND-WILDCARDS.pmod
ImportantUse upper-case letters in file names of policy modules.
Open the policy modules in a text editor of your choice and insert options that modify the system-wide cryptographic policy, for example:
# vi MYCRYPTO-1.pmod
min_rsa_size = 3072 hash = SHA2-384 SHA2-512 SHA3-384 SHA3-512
# vi SCOPES-AND-WILDCARDS.pmod
# Disable the AES-128 cipher, all modes cipher = -AES-128-* # Disable CHACHA20-POLY1305 for the TLS protocol (OpenSSL, GnuTLS, NSS, and OpenJDK) cipher@TLS = -CHACHA20-POLY1305 # Allow using the FFDHE-1024 group with the SSH protocol (libssh and OpenSSH) group@SSH = FFDHE-1024+ # Disable all CBC mode ciphers for the SSH protocol (libssh and OpenSSH) cipher@SSH = -*-CBC # Allow the AES-256-CBC cipher in applications using libssh cipher@libssh = AES-256-CBC+
- Save the changes in the module files.
Apply your policy adjustments to the
DEFAULT
system-wide cryptographic policy level:# update-crypto-policies --set DEFAULT:MYCRYPTO-1:SCOPES-AND-WILDCARDS
To make your cryptographic settings effective for already running services and applications, restart the system:
# reboot
Verification
Check that the
/etc/crypto-policies/state/CURRENT.pol
file contains your changes, for example:$ cat /etc/crypto-policies/state/CURRENT.pol | grep rsa_size min_rsa_size = 3072
Additional resources
-
Custom Policies
section in theupdate-crypto-policies(8)
man page on your system -
Crypto Policy Definition Format
section in thecrypto-policies(7)
man page on your system - How to customize crypto policies in RHEL 8.2 Red Hat blog article
3.7. Disabling SHA-1 by customizing a system-wide cryptographic policy
Because the SHA-1 hash function has an inherently weak design, and advancing cryptanalysis has made it vulnerable to attacks, RHEL 8 does not use SHA-1 by default. Nevertheless, some third-party applications, for example, public signatures, still use SHA-1. To disable the use of SHA-1 in signature algorithms on your system, you can use the NO-SHA1
policy module.
The NO-SHA1
policy module disables the SHA-1 hash function only in signatures and not elsewhere. In particular, the NO-SHA1
module still allows the use of SHA-1 with hash-based message authentication codes (HMAC). This is because HMAC security properties do not rely on the collision resistance of the corresponding hash function, and therefore the recent attacks on SHA-1 have a significantly lower impact on the use of SHA-1 for HMAC.
If your scenario requires disabling a specific key exchange (KEX) algorithm combination, for example, diffie-hellman-group-exchange-sha1
, but you still want to use both the relevant KEX and the algorithm in other combinations, see Steps to disable the diffie-hellman-group1-sha1 algorithm in SSH for instructions on opting out of system-wide crypto-policies for SSH and configuring SSH directly.
The module for disabling SHA-1 is available from RHEL 8.3. Customization of system-wide cryptographic policies is available from RHEL 8.2.
Procedure
Apply your policy adjustments to the
DEFAULT
system-wide cryptographic policy level:# update-crypto-policies --set DEFAULT:NO-SHA1
To make your cryptographic settings effective for already running services and applications, restart the system:
# reboot
Additional resources
-
Custom Policies
section in theupdate-crypto-policies(8)
man page on your system -
Crypto Policy Definition Format
section in thecrypto-policies(7)
man page on your system - How to customize crypto policies in RHEL Red Hat blog article.
3.8. Creating and setting a custom system-wide cryptographic policy
For specific scenarios, you can customize the system-wide cryptographic policy by creating and using a complete policy file.
Customization of system-wide cryptographic policies is available from RHEL 8.2.
Procedure
Create a policy file for your customizations:
# cd /etc/crypto-policies/policies/ # touch MYPOLICY.pol
Alternatively, start by copying one of the four predefined policy levels:
# cp /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/MYPOLICY.pol
Edit the file with your custom cryptographic policy in a text editor of your choice to fit your requirements, for example:
# vi /etc/crypto-policies/policies/MYPOLICY.pol
Switch the system-wide cryptographic policy to your custom level:
# update-crypto-policies --set MYPOLICY
To make your cryptographic settings effective for already running services and applications, restart the system:
# reboot
Additional resources
-
Custom Policies
section in theupdate-crypto-policies(8)
man page and theCrypto Policy Definition Format
section in thecrypto-policies(7)
man page on your system - How to customize crypto policies in RHEL Red Hat blog article
3.9. Enhancing security with the FUTURE
cryptographic policy using the crypto_policies
RHEL system role
You can use the crypto_policies
RHEL system role to configure the FUTURE
policy on your managed nodes. This policy helps to achieve for example:
- Future-proofing against emerging threats: anticipates advancements in computational power.
- Enhanced security: stronger encryption standards require longer key lengths and more secure algorithms.
- Compliance with high-security standards: for example in healthcare, telco, and finance the data sensitivity is high, and availability of strong cryptography is critical.
Typically, FUTURE
is suitable for environments handling highly sensitive data, preparing for future regulations, or adopting long-term security strategies.
Legacy systems or software does not have to support the more modern and stricter algorithms and protocols enforced by the FUTURE
policy. For example, older systems might not support TLS 1.3 or larger key sizes. This could lead to compatibility problems.
Also, using strong algorithms usually increases the computational workload, which could negatively affect your system performance.
Prerequisites
- You have prepared the control node and the managed nodes
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudo
permissions on them.
Procedure
Create a playbook file, for example
~/playbook.yml
, with the following content:--- - name: Configure cryptographic policies hosts: managed-node-01.example.com tasks: - name: Configure the FUTURE cryptographic security policy on the managed node ansible.builtin.include_role: name: rhel-system-roles.crypto_policies vars: - crypto_policies_policy: FUTURE - crypto_policies_reboot_ok: true
The settings specified in the example playbook include the following:
crypto_policies_policy: FUTURE
-
Configures the required cryptographic policy (
FUTURE
) on the managed node. It can be either the base policy or a base policy with some sub-policies. The specified base policy and sub-policies have to be available on the managed node. The default value isnull
. It means that the configuration is not changed and thecrypto_policies
RHEL system role will only collect the Ansible facts. crypto_policies_reboot_ok: true
-
Causes the system to reboot after the cryptographic policy change to make sure all of the services and applications will read the new configuration files. The default value is
false
.
For details about all variables used in the playbook, see the
/usr/share/ansible/roles/rhel-system-roles.crypto_policies/README.md
file on the control node.Validate the playbook syntax:
$ ansible-playbook --syntax-check ~/playbook.yml
Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
$ ansible-playbook ~/playbook.yml
Because the FIPS:OSPP
system-wide subpolicy contains further restrictions for cryptographic algorithms required by the Common Criteria (CC) certification, the system is less interoperable after you set it. For example, you cannot use RSA and DH keys shorter than 3072 bits, additional SSH algorithms, and several TLS groups. Setting FIPS:OSPP
also prevents connecting to Red Hat Content Delivery Network (CDN) structure. Furthermore, you cannot integrate Active Directory (AD) into the IdM deployments that use FIPS:OSPP
, communication between RHEL hosts using FIPS:OSPP
and AD domains might not work, or some AD accounts might not be able to authenticate.
Note that your system is not CC-compliant after you set the FIPS:OSPP
cryptographic subpolicy. The only correct way to make your RHEL system compliant with the CC standard is by following the guidance provided in the cc-config
package. See the Common Criteria section in the Compliance Activities and Government Standards Knowledgebase article for a list of certified RHEL versions, validation reports, and links to CC guides hosted at the National Information Assurance Partnership (NIAP) website.
Verification
On the control node, create another playbook named, for example,
verify_playbook.yml
:--- - name: Verification hosts: managed-node-01.example.com tasks: - name: Verify active cryptographic policy ansible.builtin.include_role: name: rhel-system-roles.crypto_policies - name: Display the currently active cryptographic policy ansible.builtin.debug: var: crypto_policies_active
The settings specified in the example playbook include the following:
crypto_policies_active
-
An exported Ansible fact that contains the currently active policy name in the format as accepted by the
crypto_policies_policy
variable.
Validate the playbook syntax:
$ ansible-playbook --syntax-check ~/verify_playbook.yml
Run the playbook:
$ ansible-playbook ~/verify_playbook.yml TASK [debug] ************************** ok: [host] => { "crypto_policies_active": "FUTURE" }
The
crypto_policies_active
variable shows the active policy on the managed node.
Additional resources
-
/usr/share/ansible/roles/rhel-system-roles.crypto_policies/README.md
file -
/usr/share/doc/rhel-system-roles/crypto_policies/
directory -
update-crypto-policies(8)
andcrypto-policies(7)
manual pages