The main goal of Transport Layer Security (TLS) is to ensure confidentiality and integrity of communication channels. To meet this goal, servers should always be configured so that only cryptographic blocks recognized as “secure” can be used for TLS connections.
In almost every security audit, Oneconsult reports risks related to the TLS configuration of the servers. While not so long ago quite often outdated and insecure protocol versions (SSLv2, SSLv3, TLS 1.0, TLS 1.1) were supported, this has fortunately become less and less the case – since they are officially considered obsolete. The currently most widespread protocol version TLS 1.2 supports – in contrast to the TLS 1.3 standard, which has been official since 2019 – not only secure ciphers but also those that are considered insecure to varying degrees and are found by Oneconsult with great regularity (most frequently CBC ciphers). Both can result in the confidentiality and integrity of the transmitted data not being guaranteed.
The risks mentioned can be avoided relatively easily by a “secure” TLS configuration. Mozilla provides a good tool for this in the form of a page with recommendations [1] for server-side TLS configuration. The page is updated regularly. Recently, there is also the SSL Configuration Generator [2]. The recommendations from Mozilla should help to create a “secure” TLS configuration. The page distinguishes between three configurations – two “secure” and one “insecure” (compatibility with old clients and libraries):
- “Modern”
- for modern clients without backward compatibility
- TLS 1.3 only
- Client chooses the cipher used
- “Intermediate”
- recommended for most servers
- TLS 1.2 with only “secure” ciphers and TLS 1.3
- Client chooses the cipher used
- “Old”
- Should NOT be used! This configuration contains “insecure” cryptographic blocks!
- for services used by very old clients or libraries
- TLS 1.0, TLS 1.1, TLS 1.2 also with “insecure” ciphers” in favor of compatibility and TLS 1.3
- Server chooses the cipher used
The “Old” configuration should only be used if the clients or libraries are so outdated that they could not use the services in question with the “Intermediate” configuration. It is also assumed here that the server supports TLS 1.2 – otherwise adjustments may have to be made to the cipher list. The page also contains a table showing which configuration is supported for different browsers, Java and OpenSSL, and from which version in each case.
The “Intermediate” configuration should be the means of choice for most purposes. With servers on which this configuration is implemented, all common clients can establish TLS connections.
Because TLS 1.3 is not yet widely deployed, the “Modern” configuration may significantly limit the clients that can communicate with the server via TLS. If one follows “Intermediate” or “Modern” for the TLS configuration, only “secure” ciphers are offered. The SSL Configuration Generator [2] also offers the option of generating sample code for the configuration file for various server software by specifying the Mozilla configuration (Modern, Intermediate, Old) and the server and OpenSSL version. This can be copied and pasted into the corresponding configuration files with a few adjustments (e.g. certificate paths). You can choose from common web servers (Apache, nginx, Tomcat etc.), some cloud software (AWS ALB; AWS ELB), but also databases (MySQL, PostgreSQL), mail (Dovecot) or FTP servers (ProFTPD).
So, with the tools provided by Mozilla, it is possible to create a secure TLS configuration for your own servers with little effort and without spending a lot of time in research. As a bonus to the secure TLS configuration, the reported risks in security audits mentioned at the beginning are a thing of the past for now. The UK’s National Cybersecurity Center recently published a similar guideline [3] on TLS configuration.
