Red Hat Training

A Red Hat training course is available for RHEL 8

Chapter 13. Using system-wide cryptographic policies

Crypto 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.

13.1. System-wide cryptographic policies

Once 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 so.

Red Hat Enterprise Linux 8 contains the following policy levels:

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

This policy 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 conservative security level that is believed to withstand any near-term future attacks. This level does not allow the use of SHA-1 in signature algorithms. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 3072 bits long.

FIPS

A policy level that conforms with the FIPS 140-2 requirements. This is used internally by the fips-mode-setup tool, which switches the RHEL system into FIPS mode.

Red Hat continuously adjusts all policy levels so that all libraries, except when using the LEGACY policy, provide secure defaults. 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 the Red Hat Enterprise Linux 8.

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 8, you should opt-out from cryptographic-policies for components that interact with that system.

Important

Because a cryptographic key used by a certificate on the Customer Portal API does not meet the requirements by the FUTURE system-wide cryptographic policy, the redhat-support-tool utility does not work with this policy level at the moment.

To work around this problem, use the DEFAULT crypto policy while connecting to the Customer Portal API.

Note

The specific algorithms and ciphers described in the policy levels as allowed are available only if an application supports them.

Tool for managing crypto policies

To view or change the current system-wide cryptographic policy, use the update-crypto-policies tool, for example:

$ update-crypto-policies --show
DEFAULT
# update-crypto-policies --set FUTURE
Setting system policy to FUTURE

To ensure that the change of the cryptographic policy is applied, restart the system.

Strong crypto defaults by removing insecure cipher suites and protocols

The following list contains cipher suites and protocols removed from the core cryptographic libraries in Red Hat Enterprise Linux 8. They are not present in the sources, or their support is disabled during the build, so applications cannot use them.

  • DES (since RHEL 7)
  • All export grade cipher suites (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)

Cipher suites and protocols disabled in all policy levels

The following cipher suites and protocols are disabled in all crypto policy levels. They can be enabled only by an explicit configuration of individual applications.

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

Cipher suites and protocols enabled in the crypto-policies levels

The following table shows the enabled cipher suites and protocols in all four crypto-policies levels.

 LEGACYDEFAULTFIPSFUTURE

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

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[a]

Symmetric ciphers with keys < 256 bits

yes

yes

yes

no

SHA-1 and SHA-224 signatures in certificates

yes

yes

yes

no

[a] 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

  • update-crypto-policies(8) man page

13.2. 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 5 and in some cases also with earlier releases, the less secure LEGACY policy level is available.

Warning

Switching to the LEGACY policy level results in a less secure system and applications.

Procedure

  1. To switch the system-wide cryptographic policy to the LEGACY level, enter the following command as root:

    # 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.

13.3. Switching the system to FIPS mode

The system-wide cryptographic policies contain a policy level that enables cryptographic modules self-checks in accordance with the requirements by the Federal Information Processing Standard (FIPS) Publication 140-2. The fips-mode-setup tool that enables or disables FIPS mode internally uses the FIPS system-wide cryptographic policy level.

Important

Red Hat recommends installing Red Hat Enterprise Linux 8 with FIPS mode enabled, as opposed to enabling FIPS mode later. Enabling FIPS mode during the installation ensures that the system generates all keys with FIPS-approved algorithms and continuous monitoring tests in place.

Procedure

  1. To switch the system to FIPS mode in RHEL 8:

    # fips-mode-setup --enable
    Setting system policy to FIPS
    FIPS mode will be enabled.
    Please reboot the system for the setting to take effect.
  2. Restart your system to allow the kernel to switch to FIPS mode:

    # reboot

Verification

  1. After the restart, you can check the current state of FIPS mode:

    # fips-mode-setup --check
    FIPS mode is enabled.

Additional resources

13.4. Enabling FIPS mode in a container

To enable cryptographic modules self-checks in accordance with the requirements by Federal Information Processing Standard (FIPS) Publication 140-2 in a container:

Prerequisites

Procedure

  1. Mount the /etc/system-fips file on the container from the host.
  2. Set the FIPS cryptographic policy level in the container:

    $ update-crypto-policies --set FIPS

RHEL 8.2 introduced an alternative method for switching a container to FIPS mode. It requires only using the following command in the container:

# mount --bind /usr/share/crypto-policies/back-ends/FIPS /etc/crypto-policies/back-ends
Note

In RHEL 8, the fips-mode-setup command does not work properly in a container and it cannot be used to enable or check FIPS mode in this scenario.

13.5. List of RHEL applications using cryptography that is not compliant with FIPS 140-2

Red Hat recommends to utilize libraries from the core crypto components set, as they are guaranteed to pass all relevant crypto certifications, such as FIPS 140-2, and also follow the RHEL system-wide crypto policies.

See the RHEL 8 core crypto components article for an overview of the RHEL 8 core crypto components, the information on how are they selected, how are they integrated into the operating system, how do they support hardware security modules and smart cards, and how do crypto certifications apply to them.

In addition to the following table, in some RHEL 8 Z-stream releases (for example, 8.1.1), the Firefox browser packages have been updated, and they contain a separate copy of the NSS cryptography library. This way, Red Hat wants to avoid the disruption of rebasing such a low-level component in a patch release. As a result, these Firefox packages do not use a FIPS 140-2-validated module.

Table 13.1. List of RHEL 8 applications using cryptography that is not compliant with FIPS 140-2

ApplicationDetails

FreeRADIUS

The RADIUS protocol uses MD5

ghostscript

Custom cryptogtaphy implementation (MD5, RC4, SHA-2, AES) to encrypt and decrypt documents

Grafana

Cryptographic implementations from the Golang x/crypto module (Ed25519, CBC, OCFB, …​)

ipxe

Crypto stack for TLS is compiled in, however, it is unused

libica

Software fallbacks for various algorithms such as RSA and ECDH through CPACF instructions

Ovmf (UEFI firmware), Edk2, shim

Full crypto stack (an embedded copy of the OpenSSL library)

perl-Digest-HMAC

HMAC, HMAC-SHA1, HMAC-MD5

perl-Digest-SHA

SHA-1, SHA-224, …​

pidgin

DES, RC4

qatengine

Mixed hardware and software implementation of cryptographic primitives (RSA, EC, DH, AES, …​)

samba[a]

AES, DES, RC4

valgrind

AES, hashes[b]

[a] Starting with RHEL 8.3, samba uses FIPS-compliant cryptography.
[b] Re-implements in software hardware-offload operations, such as AES-NI.

13.6. 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.

13.6.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 crypto 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 crypto 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 crypto policy in a drop-in configuration file located in the /etc/ssh/ssh_config.d/ directory, with a two-digit number prefix smaller than 50, so that it lexicographically precedes the 50-redhat.conf file, and with a .conf suffix, for example, 49-crypto-policy-override.conf.

See the ssh_config(5) man page for more information.

Additional resources

  • update-crypto-policies(8) man page

13.7. Customizing system-wide cryptographic policies with policy modifiers

Use this procedure to adjust certain algorithms or protocols of any system-wide cryptographic policy level or a full custom policy.

Note

Customization of system-wide cryptographic policies is available from RHEL 8.2.

Procedure

  1. Checkout to the /etc/crypto-policies/policies/modules/ directory:

    # cd /etc/crypto-policies/policies/modules/
  2. Create policy modules for your adjustments, for example:

    # touch MYCRYPTO1.pmod
    # touch NO-AES128.pmod
    Important

    Use upper-case letters in file names of policy modules.

  3. Open the policy modules in a text editor of your choice and insert options that modify the system-wide cryptographic policy, for example:

    # vi MYCRYPTO1.pmod
    sha1_in_certs = 0
    min_rsa_size = 3072
    # vi NO-AES128.pmod
    cipher = -AES-128-GCM -AES-128-CCM -AES-128-CTR -AES-128-CBC
  4. Save the changes in the module files.
  5. Apply your policy adjustments to the DEFAULT system-wide cryptographic policy level:

    # update-crypto-policies --set DEFAULT:MYCRYPTO1:NO-AES128
  6. To make your cryptographic settings effective for already running services and applications, restart the system:

    # reboot

Additional resources

13.8. 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.

Important

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 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.

Note

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

  1. Apply your policy adjustments to the DEFAULT system-wide cryptographic policy level:

    # update-crypto-policies --set DEFAULT:NO-SHA1
  2. To make your cryptographic settings effective for already running services and applications, restart the system:

    # reboot

Additional resources

13.9. Creating and setting a custom system-wide cryptographic policy

The following steps demonstrate customizing the system-wide cryptographic policies by a complete policy file.

Note

Customization of system-wide cryptographic policies is available from RHEL 8.2.

Procedure

  1. 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
  2. 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
  3. Switch the system-wide cryptographic policy to your custom level:

    # update-crypto-policies --set MYPOLICY
  4. To make your cryptographic settings effective for already running services and applications, restart the system:

    # reboot

Additional resources

13.10. Setting a custom cryptographic policy across systems

As an administrator, you can use the Crypto Policies System Role on RHEL to quickly and consistently configure custom cryptographic policies across many different systems using Red Hat Ansible Automation Platform.

13.10.1. Crypto Policies System Role variables and facts

In a Crypto Policies System Role playbook, you can define the parameters for the crypto policies configuration file according to your preferences and limitations.

If you do not configure any variables, the system role does not configure the system and only reports the facts.

Selected variables for the Crypto Policies System Role

crypto_policies_policy
Determines the cryptographic policy level the system role applies to the managed nodes. For details about the different crypto policy levels, see System-wide cryptographic policies .
crypto_policies_reload
If set to yes, the affected services, currently the ipsec, bind, and sshd services, reload after applying a crypto policy. Defaults to yes.
crypto_policies_reboot_ok
If set to yes, and a reboot is necessary after the system role changes the crypto policy, it sets crypto_policies_reboot_required to yes. Defaults to no.

Facts set by the Crypto Policies System Role

crypto_policies_active
Lists the currently selected policy.
crypto_policies_available_policies
Lists all available policy levels available on the system.
crypto_policies_available_modules
Lists all available subpolicy modules available on the system.

Additional resources

13.10.2. Setting a custom cryptographic policy using the Crypto Policies System Role

You can use the Crypto Policies System Role to configure a large number of managed nodes consistently from a single control node.

Prerequisites

  • Access and permissions to one or more managed nodes, which are systems you want to configure with the Crypto Policies System Role.
  • Access and permissions to a control node, which is a system from which Red Hat Ansible Engine configures other systems.

    On the control node:

    • Red Hat Ansible Engine is installed
    • The rhel-system-roles package is installed
    • An inventory file which lists the managed nodes.

Procedure

  1. Create a new playbook.yml file with the following content:

    ---
    - hosts: all
      tasks:
      - name: Configure crypto policies
        include_role:
          name: linux-system-roles.crypto_policies
        vars:
          - crypto_policies_policy: FUTURE
          - crypto_policies_reboot_ok: true

    You can replace the FUTURE value with your preferred crypto policy, for example: DEFAULT, LEGACY, and FIPS:OSPP.

    The crypto_policies_reboot_ok: true variable causes the system to reboot after the system role changes the crypto policy.

    For more details, see Crypto Policies System Role variables and facts .

  2. Optional: Verify playbook syntax.

    # ansible-playbook --syntax-check playbook.yml
  3. Run the playbook on your inventory file:

    # ansible-playbook -i inventory_file playbook.yml

Verification

  1. On the control node, create another playbook named, for example, verify_playbook.yml:

    - hosts: all
      tasks:
     - name: Verify active crypto policy
       include_role:
         name: linux-system-roles.crypto_policies
    
     - debug:
         var: crypto_policies_active

    This playbook does not change any configurations on the system, only reports the active policy on the managed nodes.

  2. Run the playbook on the same inventory file:

    # ansible-playbook -i inventory_file verify_playbook.yml
    
    TASK [debug] **************************
    ok: [host] => {
        "crypto_policies_active": "FUTURE"
    }

    The "crypto_policies_active": variable shows the policy active on the managed node.

13.10.3. Additional resources

  • For details about the parameters used in the Crypto Policies and additional information about the Crypto Policies System Role, see the /usr/share/ansible/roles/rhel-system-roles.crypto_policies/README.md file.
  • For details about the ansible-playbook command, see the ansible-playbook(1) man page.
  • Installing RHEL System Roles .
  • Applying a system role .