Why is this an issue?
This rule raises an issue when an insecure TLS protocol version (i.e. a protocol different from "TLSv1.2", "TLSv1.3", "DTLSv1.2", or "DTLSv1.3") is
used or allowed.
It is recommended to enforce TLS 1.2 as the minimum protocol version and to disallow older versions like TLS 1.0. Failure to do so could open the
door to downgrade attacks: a malicious actor who is able to intercept the connection could modify the requested protocol version and downgrade it to a
less secure version.
In most cases, using the default system configuration is not compliant. Indeed, an application might get deployed on a wide range of systems with
different configurations. While using a system’s default value might be safe on modern up-to-date systems, this might not be the case on older
systems. It is therefore recommended to explicitly set a safe configuration in every case.
Noncompliant code example
HTTP request tools such as curl, wget and Invoke-WebRequest offer the option to choose the version of
SSL/TLS that will be used for requests. The following example successfully requests data from a server with an insecure version of TLS. Thus, it is
possible that the response was intercepted or tampered with by a third party.
FROM ubuntu:22.04
# Noncompliant
RUN curl --tlsv1.0 -O https://tlsv1-0.example.com/downloads/install.sh
Compliant solution
Choosing a recent, secure version of TLS ensures that the created TLS session is secure and cannot be intercepted. In this example, the minimal
version of TLS is set to TLSv1.2, guaranteeing that requests can only be sent over TLSv1.2 or TLSv1.3.
FROM ubuntu:22.04
RUN curl --tlsv1.2 -O https://tlsv1-3.example.com/downloads/install.sh
Resources
