Guide to TLS standards compliance

The Transport Layer Security (TLS) protocol [01] 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 sites. 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 2018. (For further help, we’ve also given example configurations of the most popular web server solutions in the appendix section.)

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. They are:

  1. The Health Insurance Portability and Accountability Act (HIPAA) [01]
  2. NIST’s SP 800-52r1 guidelines [02]
  3. and the Payment Card Industry (PCI) Data Security Standard (DSS) [03].

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. It was replaced by a revised version, SP 800-52r1, in 2014. In November 2017 the draft of another revision, SP 800-52r2, was published for review, but this has not yet been adopted. Although SP 800-52r2 suggests improvements (such as more modern algorithms) users are discouraged from relying on it, due to compatibility issues with older browsers. For this reason, this article will follow the guidelines of SP 800-52r1, 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-52r1 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-52r1 states the following:

"TLS version 1.1 is required, at a minimum, in order to mitigate various 
attacks on version 1.0 of the TLS protocol. Support for TLS version 1.2 is 
strongly recommended. Servers that support government-only applications shall 
be configured to support TLS 1.1, and should be configured to support TLS 
1.2. These servers shall not support TLS 1.0, SSL 2.0, or SSL 3.0. [...] 
Agencies shall develop migration plans to support TLS 1.2 by January 1, 2015.

Servers that support citizen or business-facing applications shall be 
configured to support version 1.1 and should be configured to support version
1.2. These servers may also be configured to support TLS version 1.0 in order 
to enable interaction with citizens and businesses. These servers shall not 
support SSL version 3.0 or earlier. If TLS 1.0 is supported, the use of TLS 
1.1 and 1.2 shall be preferred over TLS 1.0

Thus, while TLS 1.0 is deprecated for government sites, NIST guidelines state that for compatibility with third-party services, government-controlled servers may implement TLS 1.0. However, the latest (and currently in effect) version of PCI-DSS [04] states that compliant servers must drop support for TLS 1.0. HIPAA technically allows use of all versions of TLS, thus the minimum commonly supported TLS version is 1.1. All of these standards, however, strongly suggest the use of TLS 1.2, which is more secure.

Cipher suites

Concerning the cipher suites contained in the NIST guidelines, NIST has released an advisory [05] recommending that all TLS implementations move away from cipher suites containing the DES cipher (or its variants) to ones using AES. The final revised list is shown below.

  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES128-GCM-SHA256
  • AES256-GCM-SHA384
  • AES128-GCM-SHA256
  • ECDHE-ECDSA-AES128-SHA256
  • ECDHE-RSA-AES128-SHA256
  • ECDHE-ECDSA-AES128-SHA
  • ECDHE-RSA-AES128-SHA
  • AES256-SHA AES128-SHA
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-SHA384
  • ECDHE-ECDSA-AES128-SHA256
  • ECDHE-ECDSA-AES256-SHA
  • ECDHE-ECDSA-AES128-SHA
  • DHE-DSS-AES256-GCM-SHA384
  • DHE-DSS-AES128-GCM-SHA256
  • DHE-DSS-AES256-SHA256
  • DHE-DSS-AES128-SHA256
  • DHE-DSS-AES256-SHA
  • DHE-DSS-AES128-SHA
  • DH-DSS-AES256-GCM-SHA384
  • DH-DSS-AES128-GCM-SHA256
  • DH-DSS-AES256-SHA256
  • DH-DSS-AES128-SHA256
  • DH-DSS-AES256-SHA
  • DH-DSS-AES128-SHA
  • ECDH-ECDSA-AES256-GCM-SHA384
  • ECDH-ECDSA-AES128-GCM-SHA256
  • ECDH-ECDSA-AES256-SHA384
  • ECDH-ECDSA-AES128-SHA256
  • ECDH-ECDSA-AES256-SHA
  • ECDH-ECDSA-AES128-SHA

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.

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 maintain your online compliance, feel free to contact us by emailing support@ssl.com, clicking the live chat button, or filling out the form below.

Appendix: Example TLS configurations

Collecting the rules stated in the three specification documents, a modern secure server should implement TLS 1.2, with a short but diverse list of selected cipher suites. As a quick reference, this example configuration file for the most popular web servers in the market are shown below:

Apache HTTP server
...
SSLProtocol                 all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite              ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder         on
SSLCompression              off
nginx
...
ssl_protocols               TLSv1.2;
ssl_ciphers                 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers   on;
httpd
...
ssl.use-sslv2             = "disable"
ssl.use-sslv3             = "disable"
ssl.honor-cipher-order    = "enable"
ssl.cipher-list           = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"
HAProxy
...
ssl-default-bind-ciphers    ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
ssl-default-bind-options    no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
ssl-default-server-ciphers  ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
ssl-default-server-options  no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
AWS ELB
"Policies": [{
                "PolicyName": "Mozilla-modern-2015-03",
                "PolicyType": "SSLNegotiationPolicyType",
                "Attributes": [
                    {
                        "Name": "Protocol-TLSv1.2",
                        "Value": true
                    },
                    {
                        "Name": "Server-Defined-Cipher-Order",
                        "Value": true
                    },
                    {
                        "Name": "ECDHE-ECDSA-AES128-GCM-SHA256",
                        "Value": true
                    },
                    {
                        "Name": "ECDHE-RSA-AES128-GCM-SHA256",
                        "Value": true
                    },
                    {
                        "Name": "ECDHE-ECDSA-AES128-SHA256",
                        "Value": true
                    },
                    {
                        "Name": "ECDHE-RSA-AES128-SHA256",
                        "Value": true
                    },
                    {
                        "Name": "ECDHE-ECDSA-AES256-GCM-SHA384",
                        "Value": true
                    },
                    {
                        "Name": "ECDHE-RSA-AES256-GCM-SHA384",
                        "Value": true
                    },
                    {
                        "Name": "ECDHE-ECDSA-AES256-SHA384",
                        "Value": true
                    }
                ]
            }]

References

  1. HIPAA PHI guidance
  2. PCI Data Security Standard
  3. NIST 800-52r1
  4. PCI-DSS deprecates TLS 1.0
  5. NIST 800-52r2 draft

Contact us for more information on how SSL.com can help you with TLS compliance:

First Name (required)

Last Name (required)

Email Address (required)

Phone Number

Company

Country (required)

Questions or Comments