Consistent security by crypto policies in Red Hat Enterprise Linux 8

Software development teams, whether open or closed source, are often composed of many groups that own individual components. Database applications typically come from a different team than ones developed by HTTP or SSH services, and others. Each group chooses libraries, languages, utilities, and cryptographic providers for their solution. Having specialized teams contributing to an application may improve the final product, but it often makes it challenging to enforce a consistent cryptographic policy on a system.

(This post was updated on March 5, 2019.) 

To counter this, security researchers from a number of 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. It is a massive, commendable effort of making sense of our security software ecosystem.

What this effort tells us, is that a heterogeneous environment requires significant effort to configure well, and that in-depth cryptographic knowledge is often required to sensibly configure new components in such a system.

At the same time, some recommendations in today’s best practices guides will be considered insecure settings at some future date, further exposing the hidden cost of the need to keep the system’s configuration up-to-date. Today, that cost is carried by IT departments, which need 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 standard  (e.g., PCI-DSS, DISA, STIG, NIST) it is trying to adhere to.

Can you assume such an expertise among users or IT departments? Not really. On the contrary, assuming that the people setting up software or systems are experts on their field, but not on details over cryptographic algorithms, may result in 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 may 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 specific risks of such misconfigurations.

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 continually expanding attack surface. This happens for multiple reasons.

One reason is to provide backward compatibility. So application configuration is often the primary mechanism for reducing an application’s attack surface, rather than removing a feature entirely.

The configuration to turn off the legacy feature is usually 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 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 attacks like POODLE (2014), FREAK (2015) or DROWN (2016) which took advantage of deprecated protocols and options, e.g., SSL 2.0 and SSL 3.0. Some attacked 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 provide a consistent crypto policy?

The good news is that starting with Red Hat Enterprise Linux 8 you may be able to defend against these attacks with our newly introduced system-wide crypto policy. This policy is included with the release of Red Hat Enterprise Linux 8.0 beta. It is a policy 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 addresses a whole class of threats by disabling legacy communication protocols such as TLS 1.1 and earlier versions, and enables systems and processes running in Red Hat Enterprise Linux to meet payment industry requirements such as the Payment Card Industry Data Security Standard (PCI-DSS). 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.

What do the existing crypto policies cover?

Crypto-policies is a component in Red Hat Enterprise Linux 8 beta which configures the core cryptographic subsystems, covering TLS, IPSec, DNSSec and Kerberos protocols¹; i.e., our supported protocols designed to provide communications security with the base operating system.

It provides a small set of policies which the administrator may select, with the default being a conservative policy offering what we believe to be more secure settings for today’s threat models and at the same time, enabling systems and processes to meet PCI-DSS requirements. Once an application runs in Red Hat Enterprise Linux it will be configured to follow the default or selected policy and refuse to fall back to algorithms and protocols not within the policy, unless the user has explicitly requested the application to do so.  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?

The four policies provided are  under the names “LEGACY”, “DEFAULT”, “FUTURE” and “FIPS”. The summaries are in the table below.

How do you use crypto policies?

The system’s policy can be set and queried with the update-crypto-policies application, as demonstrated here. 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 are  found in the update-crypto-policies manual page.

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

Any services or applications started (or restarted) after this policy change will switch to the new policies. You must restart applications for the policies to take effect.

Example with client applications

The previous example switches the system to a mode where the still widely used SHA-1 algorithm 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 https://sha1.example.com
--2018-10-12 05:27:40--  https://sha1.example.com/
Resolving sha1.example.com (sha1.example.com)... 104.112.42.112
Connecting to sha1.example.com (sha1.example.com)|104.112.42.112|:443... connected.
ERROR: The certificate of ‘sha1.example.com’ is not trusted.
ERROR: The certificate of ‘sha1.example.com’ was signed using an insecure algorithm.


$ curl https://sha1.example.com
curl: (60) SSL certificate problem: EE certificate key too weak
More details here: https://curl.haxx.se/docs/sslcerts.html

Example with server applications

On the previous examples, both applications refused to connect to that server. Let’s now see how this affects servers running on RHEL 8. On the following example, we will set up an Apache web server and try to connect 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)
- 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 restricted to an option forbidden by the server’s DEFAULT policy is notified via a TLS alert message, and the connection is closed.

Conclusion

With the examples above, we can see that both client and server applications respect the system-wide crypto policies. That not only raises 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.