Guide to TLS Standards Compliance - SSL.com (2024)

The Transport Layer Security (TLS) protocol is the primary means of protecting network communications over the Internet. This article is a brief guide to help you configure a secure server to meet current TLS standards.

Introduction

The Transport Layer Security (TLS) protocol is the primary means of protecting network communications over the Internet. It (and its predecessor, Secure Sockets Layer or SSL) have been used for decades in many applications, but most notably in browsers when they visit HTTPS websites. TLS usually functions quietly in the background, but contrary to what one might think, TLS is not a black box that just works. Rather, the security TLS provides arises from the cooperation of various cryptographic algorithms. Moreover, TLS, like SSL before it, constantly evolves with the security industry—new technology and business requirements must be satisfied, while the latest security threats must be mitigated. Algorithms can become obsolete over time, or practices can be abandoned, with each change affecting the overall security of a TLS instance (like the one protecting your connection right now).

This volatility has motivated various standards organizations to publish guideline documents, so that a minimum baseline for TLS security could be established in a particular market, sector or service. Unfortunately, there are numerous such standards, with different sectors requiring compliance with different, applicable documents, while the standards themselves also evolve over time, accommodating changes in the sector they were designed to protect.

Understandably, navigating through this sea of standards in order to set up a modern TLS instance can be a real headache for administrators. This article is a brief guide to help you configure a secure server to meet expected TLS standards in 2021. (For further help, we’ve also given example configurations of the most popular web server solutions in the appendix.)

The Standards

There are several entities that maintain guidelines for TLS with regard to network security, such as the United States Department of Health and Human Services (HHS) or the National Institute of Standards and Technology (NIST). For the sake of brevity, this article will only study the three most adopted documents:

1. The Health Insurance Portability and Accountability Act (HIPAA)
2. NIST’s SP 800-52r2 guidelines
3. The Payment Card Industry Data Security Standard (PCI-DSS)

HIPAA

HIPAA is a regulation enacted by the US government in 1996, concerning the secure handling of Protected Health Information (PHI). PHI refers to any digital patient information, such as test results or diagnoses. A HIPAA guidance document published in 2013 states the following:

Valid encryption processes for data in motion are those which comply, as appropriate, with NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113, Guide to SSL VPNs, or others which are Federal Information Processing Standards (FIPS) 140-2 validated.

NIST standards

In 2005, NIST published Special Publication (SP) 800-52, describing the correct operational procedures to securely configure a TLS instance for government servers. SP 800-52 has since been replaced by versions SP 800-52r1 (2014) and SP 80052r2 (2019). This article follows the guidelines of SP 800-52r2, which is currently stable.

PCI-DSS

PCI-DSS is a compliance standard maintained by the Payment Card Industry (PCI) Standards Security Council (SSC) which establishes how payment and card information are handled by e-commerce web sites. Regarding the proper configuration of TLS instances, PCI-DSS states:

“Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g. NIST SP 800-52 and SP 800-57, OWASP, etc.)”

TLS standards: putting these all together

It should be noted by now that each standard affects different systems, based on their function and the data they handle. For example, a hospital e-mail server can fall under HIPAA guidelines because exchanged messages might contain patient information, while the hospital’s CRM system might fall under PCI-DSS because it can contain credit card and other customer data. Being compliant with all three standards would require using common TLS parameters present in all the documents.

Fortunately, it is apparent that all standards follow NIST’s guidelines for the selection of TLS parameters. This means that, at the moment of this writing, being compliant with SP 800-52r2 should make a server compliant with HIPAA and PCI-DSS as well. (Okay, this is not exactly true, but things will get clearer in the next section.)

Configurable TLS parameters

The level of security that TLS provides is most affected by the protocol version (i.e. 1.0, 1.1, etc.) and the allowed cipher suites. Ciphers are algorithms that perform encryption and decryption. However, a cipher suite is a set of algorithms, including a cipher, a key-exchange algorithm and a hashing algorithm, which are used together to establish a secure TLS connection. Most TLS clients and servers support multiple alternatives, so they have to negotiate when establishing a secure connection to select a common TLS version and cipher suite.

TLS protocol version

Concerning TLS version support, NIST SP 800-52r2 states the following:

Servers that support government-only applications shall be configured to use TLS 1.2 and should be configured to use TLS 1.3 as well. These servers should not be configured to use TLS 1.1 and shall not use TLS 1.0, SSL 3.0, or SSL 2.0.

…

Servers that support citizen or business-facing applications (i.e., the client may not be part of a government IT system) shall be configured to negotiate TLS 1.2 and should be configured to negotiate TLS 1.3. The use of TLS versions 1.1 and 1.0 is generally discouraged, but these versions may be configured when necessary to enable interaction with citizens and businesses… These servers shall not allow the use of SSL 2.0 or SSL 3.0.

Agencies shall support TLS 1.3 by January 1, 2024. After this date, servers shall support TLS 1.3 for both government-only and citizen or business-facing applications. In general, servers that support TLS 1.3 should be configured to use TLS 1.2 as well. However, TLS 1.2 may be disabled on servers that support TLS 1.3 if it has been determined that TLS 1.2 is not needed for interoperability.

While TLS 1.0 is prohibited and TLS 1.1 is deprecated for government sites, NIST guidelines state that for compatibility with third-party services, government-controlled servers may implement TLS 1.0 and 1.1 when necessary. Under PCI-DSS 3.2.1 (the current version), compliant servers must drop support for TLS 1.0 and “migrate to a minimum of TLS 1.1, Preferably TLS 1.2.” HIPAA technically allows use of all versions of TLS. Thus the minimum commonly supported TLS version is 1.1; however, PCI-DSS and NIST strongly suggest the use of the more secure TLS 1.2 (and, as seen above, NIST recommends adoption of TLS 1.3 and plans to require support by 2024).

Cipher Suites

TLS 1.2 and Earlier

SP 800-52r2 specifies a variety of acceptable cipher suites for TLS 1.2 and earlier. The standard does not require support for any particular cipher suites, but offers guidance on choosing stronger ones:

1. Prefer ephemeral keys over static keys (i.e., prefer DHE over DH, and prefer ECDHE over ECDH). Ephemeral keys provide perfect forward secrecy.
2. Prefer GCM or CCM modes over CBC mode. The use of an authenticated encryption mode prevents several attacks (see Section 3.3.2 [of SP 800-52r2] for more information). Note that these are not available in versions prior to TLS 1.2.
3. Prefer CCM over CCM_8. The latter contains a shorter authentication tag, which provides a lower authentication strength.

Furthermore, although these are the permitted cipher suites, if your TLS server does not deal with large variety of different platforms and clients, it is recommended that only a small subset of these algorithms be used. Allowing more cipher suites can only widen the attack surface to your server if (or when) a new protocol vulnerability is discovered.

TLS 1.3

TLS 1.3 has a much shorter list of cipher suites:

• TLS_AES_128_GCM_SHA256 (0x13, 0x01)
• TLS_AES_256_GCM_SHA384 (0x13, 0x02)
• TLS_AES_128_CCM_SHA256 (0x13, 0x04)
• TLS_AES_128_CCM_8_SHA256 (0x13, 0x05)

Conclusion

We hope this brief guide will help you understand more about TLS, and assist you when configuring TLS on your own server. With respect to the standards and recommendations we’ve discussed, the following section contains an example configuration which you should be able to apply to the most popular web server solutions. If you have any questions on how to maintain your online compliance, feel free to contact us by emailing [email protected] or clicking the live chat button at the bottom of this screen.

Appendix: Example TLS configurations

Collecting the rules stated in the three specification documents, a modern secure server should implement TLS 1.2 and/or TLS 1.3, with a short but diverse list of selected cipher suites. As a quick reference, example configurations for the most popular web servers in the market are shown below. These are “intermediate” (general-purpose) configurations generated with Mozilla’s SSL Configuration Generator:

...SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384SSLHonorCipherOrder offSSLSessionTickets off

...ssl_protocols TLSv1.2 TLSv1.3;ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;ssl_prefer_server_ciphers off;

...ssl.openssl.ssl-conf-cmd = ("Protocol" => "ALL, -SSLv2, -SSLv3, -TLSv1, -TLSv1.1")ssl.cipher-list = "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"ssl.honor-cipher-order = "disable"

...ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 no-tlsv11 no-tls-ticketsssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

...Policies: - PolicyName: Mozilla-intermediate-v5-0 PolicyType: SSLNegotiationPolicyType Attributes: - Name: Protocol-TLSv1.2 Value: true - Name: Server-Defined-Cipher-Order Value: false - Name: ECDHE-ECDSA-AES128-GCM-SHA256 Value: true - Name: ECDHE-RSA-AES128-GCM-SHA256 Value: true - Name: ECDHE-ECDSA-AES256-GCM-SHA384 Value: true - Name: ECDHE-RSA-AES256-GCM-SHA384 Value: true - Name: DHE-RSA-AES128-GCM-SHA256 Value: true - Name: DHE-RSA-AES256-GCM-SHA384 Value: true