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.
Policy name |
Description
|
---|---|
LEGACY
|
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.
|
DEFAULT2
|
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.
|
FUTURE
|
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.
|
FIPS
|
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)... 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.
À propos de l'auteur
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.
Contenu similaire
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit