Transport Layer Security

This page is not complete.

The security of any connection using Transport Layer Security (TLS) is heavily dependent upon the cipher suites and security parameters selected. This article's goal is to help you make these decisions to ensure the confidentiality and integrity communication between client and server. The Mozilla Operations Security (OpSec) team maintains a wiki entry with reference transport layer security configurations.

The Transport Layer Security (TLS) protocol is the standard for enabling two networked applications or devices to exchange information privately and robustly, without having to worry about data integrity. Within TLS, applications have their choice of cipher suites and security parameters, and these decisions can have a substantial impact on the security and reliability of your data. This article provides an overview of TLS and the kinds of decisions you need to make when securing your content.


When HTTPS was introduced, it was based on Secure Sockets Layer (SSL) 2.0, a technology introduced by Netscape. It was updated to SSL 3.0 not long after, and as its usage expanded, it became clear that a common, standard encryption technology needed to be specified to ensure interoperability among all web browsers and servers. The Internet Engineering Task Force (IETF) specified TLS 1.0 in RFC 2246 in January, 1999. That RFC was updated to TLS 1.1 in April, 2006, and TLS 1.2 (RFC 5246) was introduced in August, 2008. Further work to enhance and improve TLS continues today.

Despite the fact that the web now uses TLS for encryption, many people still refer to it as "SSL" out of habit.

By default, HTTP/2 requires the use of TLS 1.2 or later, unless you explicitly open the connection in HTTP/2 Cleartext mode by specifying "h2c" as the value of the HTTP Upgrade header when upgrading from HTTP to HTTP/2.

TLS 1.3 differs significantly from previous versions, and is not interoperable with them. See Changes in TLS 1.3 for details.


Although TLS can be used on top of any low-level transport protocol, our primary interest in it is in its use to encrypt HTTP traffic. HTTP encrypted using TLS is commonly referred to as HTTPS, and TLS-encrypted web traffic is by convention exchanged on port 443 by default, while unencrypted HTTP uses port 80 by default.

TLS provides three primary services that help ensure the safety and security of data exchanged with it:

Authentication lets each party to the communication verify that the other party is who they claim to be.
Data is encrypted while being transmitted between the user agent and the server, in order to prevent it from being read and interpreted by unauthorized parties.
TLS ensures that between encrypting, transmitting, and decrypting the data, no information is lost, damaged, tampered with, or falsified.

Cipher suites

A cipher suite is a set of algorithms that together support the secure authentication, encryption, and exchange security configurations during the process of starting a TLS connection. Since TLS permits both user agents and servers to support a number of cipher suites, a handshaking process takes place while establishing a connection. This process is invisible to web content, since it's handled by the user agent, the server, and/or the operating system(s) involved in the exchange.

The components of a cipher suite have changed significantly in TLS 1.3. For that reason (among others), TLS 1.3 is not backward-compatible with TLS 1.2.

Each cipher's name may be written diffferent ways by different libraries. IANA, OpenSSL, and GnuTLS often use different naming (Mozilla's NSS uses the IANA naming). The cipher names correspondence table on the Mozilla OpSec team's article on TLS configurations lists these names as well as their compatibility levels.

Configuring your server

Correctly configuring your server is crucial. In general, you should try to limit cipher support to the newest ciphers possible which are compatible with the browsers you want to be able to connect to your site. The Mozilla OpSec guide to TLS configurations provides three recommended configurations. As of this writing, those configurations are:

Compatible only with more recent browsers, this only supports the most recent and secure cipher suites, and only supports TLS version 1.2 and later. This limits browser support to at a minimum Chrome 30, Firefox 27, Internet Explorer 11 on Windows 7, any version of Microsoft Edge, Opera 17, Safari 9, Android Browser 5.0, and Java 8.
While not supporting legacy browsers, the intermediate configuration does add support for a wide assortment of browsers. It supports TLS version 1.0 and later, and is compatible with all versions of Firefox, Chrome, and Safari, as well as Opera 5 and later and Internet Explorer 7 and later.
Old (backward compatible)
The old configuration supports all clients back to Internet Explorer 6 on Windows XP, and should only be used if absolutely necessary, as it's relatively insecure by current standards. This supports all versions of TLS as well as SSLv3. Just about every cipher that isn't either outright broken and dangerous to use is supported by this configuration, which means you should think very carefully before using it!

To assist you in configuring your site, Mozilla provides a helpful TLS configuration generator that will generate configuration files for the following Web servers:

  • Apache
  • Nginx
  • Lighttpd
  • HAProxy
  • Amazon Web Services CloudFormation Elastic Load Balancer

Using the configurator is a recommended way to create the configuration to meet your needs; then copy and paste it into the appropriate file on your server and restart the server to pick up the changes. The configuration file may need some adjustments to include custom settings, so be sure to review the generated configuration before using it; installing the configuration file without ensuring any references to domain names and the like are correct will result in a server that just doesn't work.

Changes in TLS 1.3

TLS 1.3 differs from TLS 1.2 and earlier in several substantial ways in addition to the cipher suite changes; these changes result in it not being directly compatible with the earlier versions of TLS. Some of the major differences include (but aren't limited to):

  • Support for older symmetric algorithms has been removed from the specification. Remaining symmetric algorithms are Authenticated Encryption with Associated Data (AEAD) algorithms.
  • The initial "ServerHello" handshake message is now the only message which isn't encrypted.
  • A new "EncryptedExtension" message now lets various extensions that were previously sent as cleartext be encrypted instead.
  • Overall, the handshake process has been simplified. It's more consistent and unnecessary messages have been removed.
  • All public key-based key exchange algorithms are now required to provide forward security. Because of that, the static RSA and Diffie-Hellman cipher suites have been removed from the specification's list of supported algorithms.
  • Elliptic Curve Cryptography (ECC) has been added to the base specification (rather than being an extension). In addition, it includes new signature algorithms (for example, the Edwards-Curve Digital Signature AlgorithmsRFC 8032, section 5.1 and RFC 8032, section 5.2.
  • Point format negotiation has been removed. Instead, each curve now uses a single point format.
  • The authentication and key exchange mechanisms have ben separated from the record protection algorithm.
  • Compression and custom Ephemeral Diffie-Hellman (DHE) groups have been removed.
  • RSA padding has been changd to use Probablilistic Signature Scheme (PSS).
  • Digital Signature Algorithm (DSA) is no longer allowed.
  • A mode supporting a round-trip time (RTT) of zero has been added. This can save a round trip during connection setup in certain situations, albeit at the expense of certain security properties.
  • The key derivation functions have been redesigned to allow them to be more easily analyzed by cryptographers. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is the underlying primitive for these.
  • Rather than negotiating versions as was done in TLS 1.2, TLS 1.3 now uses a version list in an extension.

For a complete list of major differences, see The Transport Layer Security (TLS) Protocol Version 1.3 specification draft, section 1.3.

TLS handshake timeout values

If the TLS handshake starts to become slow or unresponsive for some reason, the user's experience can be affected significantly. To mitigate this problem, modern browsers have implemented handshake timeouts:

  • Since version 58, Firefox implements a TLS handshake timeout with a default value of 30 seconds. The timeout value can be varied by editing the network.http.tls-handshake-timeout pref in about:config.

See also

Document Tags and Contributors

 Contributors to this page: chrisdavidmills, Sheppy, rolfedh, adithya_mani, marumari
 Last updated by: chrisdavidmills,