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 protocols1; 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.
This policy is aimed at compatibility with legacy systems; it is considered less secure and it includes support for TLS 1.0, IKEv1, 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.
The DEFAULT policy is a reasonable default policy for today's standards. 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.
A more 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 and Diffie-Hellman parameters are accepted if larger than 3071-bits.
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-2 compliance mode.
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)... 184.108.40.206 Connecting to sha1.example.com (sha1.example.com)|220.127.116.11|: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 : 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.
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.
About the author
Nikos Mavrogiannopoulos has a background in mathematics and holds a Ph.D. in cryptography. Spent two decades in software engineering, mostly in security of back-end software; formed the RHEL cryptographic team. I'm now a manager in RHEL Security Engineering.