Contact Us

TLS (Transport Layer Security)

Field: Security · Also called: Transport Layer Security, SSL/TLS

Transport Layer Security (TLS) is the IETF protocol that protects communication between a client and a server, such as a web browser and a web server, against eavesdropping, tampering, and message forgery. It supersedes the Secure Sockets Layer (SSL) protocol it was based on.

In the McCumber Cube, TLS is a technology measure for information in the transmission state, what is now usually called data in transit. It protects the confidentiality and integrity of that data, and RFC 8446 adds authentication: “The server side of the channel is always authenticated; the client side is optionally authenticated.” TLS does not protect the data once it is stored or processed at either end; those states need their own measures.

TLS is sometimes informally called HTTPS, but HTTPS is a specific use of it: HTTP carried over TLS. RFC 2818 describes how “to use TLS to secure HTTP connections,” and RFC 9110 defines the https URI scheme in terms of a server “capable of establishing a TLS” connection secured for HTTP.

TLS supersedes SSL

TLS 1.0 was published in 1999 as RFC 2246, which says it is “based on the SSL 3.0 Protocol Specification as published by Netscape,” with differences “significant enough that TLS 1.0 and SSL 3.0 do not interoperate.” The IETF has since retired every SSL version and the early TLS versions: RFC 6176 prohibits SSL 2.0 (2011), RFC 7568 requires that SSL 3.0 “not be used” (2015), and RFC 8996 deprecates TLS 1.0 and 1.1 (2021). TLS 1.2 and TLS 1.3 (RFC 8446, 2018) remain. The older name persists in everyday use, as in “SSL certificate” and the OpenSSL library, for what is in practice TLS.

Which versions to accept

RFC 8996 gives the technical reasons TLS 1.0 and 1.1 were deprecated. The integrity of their handshake “depends on a running SHA-1 hash,” which makes a downgrade attack possible “by an attacker able to perform 277 operations, well below the acceptable modern security margin.” Authentication of the peers depends on SHA-1 signatures as well, and neither version supports authenticated encryption (AEAD) cipher suites, “which were not supported prior to TLS 1.2.”

TLS 1.2 is therefore the minimum in current standards. RFC 8996 directs implementers to “migrate to a minimum of (D)TLS 1.2.” NIST SP 800-52 Rev. 2 requires TLS 1.2 on all government TLS servers and clients, and support for TLS 1.3 by January 1, 2024. For payment card data, the PCI Security Standards Council states that after June 30, 2018, “SSL and Early TLS may no longer be used as a security control for PCI DSS,” with a narrow exception for some point-of-sale terminals. TLS 1.3 is preferable wherever both ends support it; among other changes, it removes static RSA and Diffie-Hellman key exchange, so that “all public-key based key exchange mechanisms now provide forward secrecy.”

The minimum is enforced by the server’s configuration. The client offers the versions it supports, and RFC 8446 says “Servers MUST only select a version of TLS present in” that offer, so a server configured to refuse anything below TLS 1.2 refuses an older client rather than falling back to a weaker version. The cost is compatibility: a client that cannot be upgraded, such as an embedded device built on an older TLS library, cannot connect until it is.

Sources

See also

Go deeper

Articles

Videos