Cryptographic protocols and algorithms have a limited lifetime—much like everything else in technology. Algorithms that provide cryptographic hashes and encryption as well as cryptographic protocols have a lifetime after which they are considered either too risky to use or plain insecure. In this post, we will describe the changes planned for the 6.9 release of Red Hat Enterprise Linux 6, which is already on Production Phase 2.

Balancing Legacy Use Cases and Modern Threats

For the RHEL operating system, which has its useful lifetime measured in decades, in addition to adding new features, it is necessary to periodically revisit default settings and phase out (or completely deprecate) protocols and algorithms the use of which—accidental or intentional—could cause irreparable damage. At the same time we must ensure that the vast majority of existing and legacy applications continues to operate without changes, as well as provide mechanisms for the administrator to revert any changes, when necessary, to the previous defaults.

What Are the Threats?

Given that any change in application or library default settings cannot be without side-effects, it is important to provide the context under which such changes are necessary. In the past few years, we’ve identified several protocol attacks with real-world impact that relied on obsolete and legacy algorithm and protocol configurations. A few prominent attacks are briefly described below:

• DROWN in 2016; it relied on servers enabling the SSL 2.0 protocol, allowing the attackers to obtain sufficient information to decrypt other, unrelated TLS sessions.
• SLOTH in 2016; it relied on clients enabling the MD5 algorithm, broken since 2004; it allowed attackers to decrypt TLS sessions.
• LOGJAM and FREAK in 2015. While the details of the attacks differ, both of these attacks relied on export cryptography being enabled in the server, allowing an attacker to decrypt TLS sessions.

Why Would Insecure Configuration Remain Enabled?

While all of the exploited protocols and algorithms were known to be obsolete or insecure for more than a decade, the impact of these attacks was still high. That indicates that these obsolete protocols and algorithms were enabled on Internet servers possibly due to:

• misconfiguration,
• administrators’ hope of improving compatibility with legacy clients,
• re-use of old configuration files.

Traditionally, we have not been very keen on deprecating algorithms and protocols throughout the RHEL timeline to avoid breaking existing and legacy applications. This was because of our belief that for an operating system, keeping operations going on is more important than addressing flaws that may not be applicable on every operating system setup.

Solution for RHEL 6.9

However, after considering these attacks and the fact that it is unrealistic to expect all administrators to keep up with cryptographic advances, we have decided to provide a protection net, which will prevent future cryptographic attacks due to accidental misconfiguration with legacy algorithms and protocols in default RHEL 6.9 installations.

No Export Ciphersuites and SSL 2.0

In particular, we will take steps that will ensure that the TLS ciphersuites marked as export, as well as the SSL 2.0 protocol, are completely removed from the operating system. These two points involve algorithms with no real-world use and a protocol that has been considered deprecated for more than 20 years. We will not provide a way to re-enable these options because we are convinced that these are primarily used to attack misconfigured systems rather than for real-world use cases.

Limited MD5, RC4, and DH

In addition, we will ensure that no application can be used with insecure signature-verification algorithms such as MD5, and that TLS client applications refuse to communicate with servers that advertise less than 1024-bit Diffie-Hellman parameters. The latter would ensure that LOGJAM-style of attacks are prevented. Furthermore, we will disable the usage of RC4 in contexts where this will not introduce compatibility issues.

All-around Application Support for TLS 1.2

While deprecating insecure algorithms and protocols protects applications running in RHEL from future attacks taking advantage of them, it is also important, given that RHEL 6.9 entered Production Phase 2, to provide a solid cryptographic base for the remaining lifetime of the product. For that we will ensure that all the back-end cryptographic components support TLS 1.2, allowing new applications to be deployed and used during its lifetime.

Summary of Changes to Cryptographic Back-ends in RHEL 6.9