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.
저자 소개
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.
유사한 검색 결과
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.