System-wide crypto policies in RHEL 8

Updated -

NOTE: This is a continuously updated version of the article: "Consistent security by crypto policies in Red Hat Enterprise Linux 8"

The software ecosystems today, whether open or closed source, are characterized by diversity. The database applications typically come from a different team than the one developed the HTTP or SSH services, and so on. Each team chooses their own libraries, languages, utilities and cryptographic providers for their solution. That diversity gives an immense strength due to focused application-specific communities and teams but it often makes it challenging to enforce a consistent cryptographic policy on a system. Security researchers from several universities and organizations have put together the ‘Applied Crypto Hardening’ guide, a 110-page guide of theory and instructions to configure a system with vetted cryptographic settings. They go through web server applications (apache, nginx), OpenSSH server, TLS use in mail servers, etc. It is a massive, commendable effort of making sense of our security software ecosystem.

What this effort additionally unveils, is that a heterogeneous environment requires significant effort to correctly configure, and also that deep cryptographic knowledge is often required to sensibly configure new components in such a system. At the same time, what is described in today’s best practices guides will be considered insecure settings at some future date, further unveiling the hidden cost of the need to keep the system’s configuration up-to-date. Today, that cost is carried by IT departments, which irrespective of the automation or configuration management, have to ensure that the cryptographic configuration on all of their supported services is reasonable and follows the industry’s standard practices as defined by the respective body (e.g., PCI-DSS, DISA, STIG, NIST).

Can we assume such an expertise among users or IT departments? Not lightly. On the contrary, we believe that assuming that the people setting up software or systems are experts on their field but not on details over cryptographic algorithms, will result to safer systems. Nevertheless, it is imperative that systems are operating under the right cryptographic settings, to reduce risk from existing and future attacks. Furthermore, we need settings that do not harm interoperability, while at the same time are conservative, conform to widely accepted standards, and eliminate legacy protocols and algorithms which are likely to become a liability.

In short, we have a configuration problem which we cannot assume the end-user or IT departments are responsible to address. Before going further on describing our solution, let’s present the risks of such misconfiguration in a more specific way.

How substantial is the risk of an inconsistent or outdated crypto policy?

As software gets continuously enhanced with new features, legacy features often remain enabled, creating a continuously expanding attack surface. There are multiple reasons for that, but the main is that in order to provide backwards compatibility, the application configuration is often the primary mechanism for reducing an application’s attack surface. That configuration is available to the end-user or system administrator. In practice, as previously mentioned, delegating such decisions to the end-users or system administrator is not very effective. Even when the required skill set is available for such a task, going to each and every application to customize its configuration based on recent cryptographic advances is a Sisyphean one, and in practice it is often a neglected task.

Subsequently, that lack of attention, increases the risk of an adversary taking advantage of an expanded attack surface. In fact, we have recently seen impactful attacks like POODLE (2014), FREAK (2015) or DROWN (2016) which took advantage of deprecated protocols and options, e.g., SSL2.0 and SSL3.0, some to attack unrelated sessions on the same server which seemingly used a modern and secure protocol. Their impact, although hard to evaluate precisely, was a blow on the perceived trustworthiness of modern systems, and served as an alarm towards the need for up-to-date and consistent cryptographic policy in system services.

How does Red Hat Enterprise Linux 8 provides a consistent crypto policy?

The good news is that, if you are a Red Hat Enterprise Linux user, you can prevent these attacks with our newly introduced system-wide crypto policy, which is included with the release of Red Hat Enterprise Linux 8.0. It is a policy which is applied consistently to running services and is kept up-to-date as part of the software updates, to stay in par with cryptographic advances.

Additionally, the selected as default policy is a conservative policy, which eliminates a whole class of threats by disabling legacy communications protocols such as TLS 1.1 and earlier versions. At the same time, we provide the option to adjust settings to local requirements, e.g., make the selected policy stricter, or more lax, for compatibility with older systems, or meeting payment industry’s requirements such as PCI-DSS (see also crypto policy customization).

What do the existing crypto policies cover?

Crypto-policies is a component in Red Hat Enterprise Linux 8 which configures the core cryptographic subsystems, covering TLS, IPSec, DNSSec and Kerberos protocols; i.e., our supported secure communications protocols on the base operating system. It provides a small set of policies which the administrator can select, with the default being a conservative policy offering secure settings for today’s threat models. Once an application runs in RHEL it will follow the default or selected policy and refuse to fall back to refuse to fall back to algorithms and protocols not within the policy, unless the user has explicitly requested the application to do so. That is, the policy applies to the default behavior of applications when running with the system-provided configuration, but can be overridden by the user if required so on an application-specific basis.


Which are the provided policies?

Four policies are provided under the names “LEGACY”, “DEFAULT”, “FUTURE” and “FIPS”. The detailed settings available on each policy are summarized in this linked article and the update-crypto-policies manual page.

How do you use crypto policies?

The system’s policy can be set and queried with the update-crypto-policies application, as demonstrated below. We will use the update-crypto-policies tool to switch the running system from the default policy, to the more strict FUTURE one. A more detailed summary of the tool’s options can be found in the update-crypto-policies manual page.

$ update-crypto-policies --show

# update-crypto-policies --set FUTURE
Setting system policy to FUTURE

Any services or applications started after this policy change will switch to the new policies.

Example with client applications

The example above switches the system to a mode where the still widespread used SHA-1 is disallowed. The following examples show the outcome of an attempt to connect to a server which contains a certificate signed with SHA-1, while the system is in the FUTURE mode which prohibits that algorithm.

# update-crypto-policies --set FUTURE
# yum install -y wget curl

$ wget
--2018-10-12 05:27:40--
Resolving (
Connecting to (||:443... connected.
ERROR: The certificate of ‘’ is not trusted.
ERROR: The certificate of ‘’ was signed using an insecure algorithm.

$ curl
curl: (60) SSL certificate problem: EE certificate key too weak
More details here:

Example with server applications

On the examples above both applications refused to connect to that server. Let’s now see how would this affect servers running on RHEL 8. On the following example we will set up an Apache Web server and try to connect to it using the gnutls-cli TLS debug tool. Initially the connection will be using the default settings with TLS 1.3 being the advertised version, and then we will instruct the tool to switch to the TLS 1.1 protocol which is not allowed by the server’s DEFAULT policy.

# update-crypto-policies --set DEFAULT
# yum module install -y httpd
# yum install -y gnutls-utils
# systemctl start httpd

$ gnutls-cli localhost --insecure </dev/null
- Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: SECP256R1
 - Curve size: 256 bits
- Version: TLS1.3
- Server Signature: RSA-PSS-RSAE-SHA256
- Cipher: AES-256-GCM
- Options:
- Handshake was completed

The initial connection attempt was a success. Let’s now try connecting with TLS 1.1 being the only version advertised by the client.

$ gnutls-cli localhost --insecure --priority "NORMAL:-VERS-ALL:+VERS-TLS1.1" </dev/null
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [70]: Error in protocol version
*** handshake has failed: A TLS fatal alert has been received.

Hence we see that a client which is restricted to an option forbidden by the server’s DEFAULT policy is notified via a TLS alert message, and the connection is closed.


With the examples above, we can see that both client and server applications respect the system-wide crypto policies, and that not only increases the security bar of default installations in Red Hat Enterprise Linux systems, but more importantly offloads the administrator from the task of figuring the right settings for cryptographic algorithms and protocols.


"At the same time, we provide the option to adjust settings to local requirements..."

How about an example? This took way longer to figure out than it should have done:

cp /usr/share/crypto-policies/policies/NO-SHA1.pmod /etc/crypto-policies/policies/modules/PCI-DSS.pmod
cat >> /etc/crypto-policies/policies/modules/PCI-DSS.pmod << EOF
mac = -HMAC-SHA1
ssh_cipher = -AES-256-CBC -AES-128-CBC
update-crypto-policies --set DEFAULT:PCI-DSS

Thanks for the comment. This article predated the customization so the adjustment referred to the ability to switch between the predefined levels. As we have the customization now it makes sense as you mention to refer to it. I've updated the text to refer to the right article explaining it.

Nikos, Thank you for updating the KB. I now understand that "Blog" in the Customer Portal search is not the same thing as "the Red Hat Blog". Will the CP search be integrated with the new blog? Or could the linked blog post be turned into a KB article?