Transport Layer Security is on the short list for “most important security protocol on the Internet.” It is designed to enable client-server applications like web browsers and servers to securely communicate over the Internet, protecting against eavesdropping, tampering, and message forgery. Each party can know that the other is who they claim to be.

TLS is the technological descendant of Secure Sockets Layer and is often referred to casually as SSL. The earlier SSL versions were developed by Netscape Communications. In the late 1990s, after AOL bought Netscape, the Internet Engineering Task Force (IETF) took over the protocol. Version 1.0 of TLS had only small differences compared with SSL 3.0. For purposes here, I’ll use the name TLS, except where making historical references to old versions. The current version of TLS is 1.3, defined in RFC 8446.

What does TLS do?

We all know TLS from the lock icon in web browsers, showing that the site is secure, but the world of TLS is much bigger than that. It has three major functions:

  • The connection is encrypted and therefore secure from monitoring.
  • The parties can be authenticated using X.509 certificates, digital signatures, and public key encryption.
  • The connection is secure from tampering because each message includes a message authentication code (MAC).

The better known and more complicated part of TLS encryption is the asymmetric part, usually using public key infrastructure (PKI). The encryption in the actual data communications is symmetric, using keys that were generated, exchanged, and agreed upon by the parties using the asymmetric handshaking part of TLS.

Symmetric encryption is designed for speed and security. Examples of symmetric algorithms are Twofish and the now-dominant Advanced Encryption Standard (AES). Asymmetric encryption establishes a secure connection between two parties that don’t necessarily trust each other.

Digital certificates with public keys, identities, and signatures are used by the parties in a TLS communication to identify each other and generate keys. Usually, but optionally, the certificates are issued by a trusted third party, called a certificate authority (CA). The parties can use public key encryption algorithms and communicate with the CA to “prove” (given some assumptions) that the party that issued the certificate is in fact who they claim to be. This is how the browser knows, for example, that the website www.hpe.com is actually Hewlett Packard Enterprise.

The MAC is conceptually similar to a cryptographic hash in that it allows a recipient to use it to prove that the message content has not been modified. However, it has different forms of attack in mind. TLS is a TCP-based protocol, but there is a User Datagram Protocol version called Datagram Transport Layer Security. The application using DTLS has to deal with packet loss and reordering with encrypted data, but it avoids problems that can occur, for example, in virtual private networks, when TCP is encapsulated in a TCP tunnel.

The handshake

The negotiation between a client and server when establishing a TLS connection is called the handshake, described broadly below. The full version, in grinding detail, is found in the specification.

All TLS handshakes authenticate the server to the client. They can, but don’t have to, authenticate the client to the server. The basic handshake, the type used when you connect to a TLS website such as a bank, does not authenticate a client. (It’s worth noting that the handshake changed quite a bit in TLS 1.3, the current, but still emerging, new version.)

In the basic handshake, the client begins with a ClientHello message to the server. This message specifies the highest TLS version it can support and suggested protocols, like cipher suites, it wishes to use. It also specifies a key agreement algorithm and a key share for the algorithm. This is enough for the server to finish the handshake and reply with encrypted packets, initially sending the algorithms it has chosen, a digital certificate containing keys, and a digital signature. (The TLS 1.2 handshake had an extra set of round trips between the client and server, and so TLS 1.3 is potentially much faster to connect.)

At the end of the process, the client has the information with which it can authenticate the server using the digital signatures returned in the handshake. It does so by checking the certificate with the issuing certificate authority.

Major applications and libraries

Netscape created SSL in order to permit encrypted communications between the browser and server. At that time, people were just beginning to do serious things with the web, such as sending credit card numbers, which meant some attempt at security was necessary. And so SSL and then TLS became the standard method of providing and indicating security in web browsers. This is certainly the most common application of it, but there are many others.

Many of the important Internet protocols that began as clear-text (unencrypted) protocols, just as HTTP began, have been augmented with TLS capabilities:

  • RFC 8314 is titled “Cleartext Considered Obsolete: Use of Transport Layer Security for Email Submission and Access.” Simple Mail Transfer Protocol and other mail protocols can now have authenticated and encrypted connections.
  • RFC 4217 defines “Securing FTP with TLS,” a.k.a. FTPS, a version of the old File Transfer Protocol over TLS. Do not confuse this with SSH (Secure Shell) File Transfer Protocol (SFTP), which runs FTP in an SSH environment.
  • DNS over TLS secures access to use of a name server.
  • Some VPNs, such as OpenConnect and OpenVPN, use TLS as a medium.

These days, many applications use a web browser as the interface and so get TLS for free as part of HTTPS.

There are many implementations of SSL. Use them. There is a rule in programming about encryption: It’s very hard to do it right. Now and then people attempt to roll their own and they usually get into trouble.

  • Windows Secure Channel: This is the standard Windows TLS library. It’s available to all applications, although many use other libraries like the ones below.
  • OpenSSL: For many years, OpenSSL was the main open source SSL/TLS library. Its reputation took a major hit after the revelation of the Heartbleed bug, leading to several forks of the code.
  • Mozilla Network Security Services (NSS): Mozilla wrote its own library for its products, and like all Mozilla products, it is open source.
  • Java Secure Sockets Extension: This is TLS for Java code.
  • Apple Secure Transport: Apple has its own in-house TLS library for its products.
  • LibreSSL: Run by the OpenBSD project, LibreSSL is one of the OpenSSL forks established post-Heartbleed.
  • BoringSSL: This is a fork of OpenSSL by Google. It is open source, but the point is for it to serve Google’s needs.

As with all software, it’s important with TLS to pay attention to vulnerability disclosures and updates, and to apply the updates quickly. There is a general appreciation of the importance of this practice for operating systems and some major applications, so updates to Windows Secure Channel, Apple Secure Transport and Mozilla NSS are likely to be updated quickly. This is not necessarily so for less prominent and in-house applications built with OpenSSL or some other library. These applications may need to be reissued or updated by the authors.

Out with the old

Each major version of TLS, at least since 1.1, has included important security improvements. Over time, old versions have been declared “prohibited.” In March 2011, the IETF published RFC 6176, requiring that clients and servers “never negotiate the use of Secure Sockets Layer (SSL) version 2.0.” In June 2015, RFC 7568 required that “SSLv3 not be used.”

In October of 2018, Apple, Google, Microsoft, and Mozilla all declared that they would deprecate TLS 1.0 and 1.1 in their products in or around March 2020. Every significant and currently supported TLS implementation supports version 1.2. In some old versions of Windows, TLS 1.2 is not enabled by default, but these versions will have reached their expiration dates by the time TLS 1.0 and 1.1 are put out to pasture.

Version 1.0 was not significantly different from SSL 3.0, but it was different enough that it was not interoperable with the old version. Because of market realities at the time of release, it contains a mechanism through which the TLS 1.0 server could revert to SSL 3.0. In effect, this was a vulnerability making all SSL 3.0 problems also problems in TLS 1.0.

The vulnerability addressed in TLS 1.1, released in April 2006 as RFC 4346, was cipher block chaining attacks. This is a class of attack with which an attacker can use protocol weaknesses in version 1.0 to encrypt and decrypt data without the key, where certain ciphers are used.

TLS 1.2 was published in August 2008 as RFC 5246, removing support for old and weak cryptography functions and strengthening many security features. Examples include:

  • Support was removed for old, weaker algorithms like the MD5 and SHA1 hash algorithms and the IDEA and DES cipher suites.
  • New, stronger algorithms like the HMAC-SHA256 cipher suites were added. Implementation of the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite was made mandatory.
  • Loose requirements in the protocol were tightened—for instance, many alerts that were optional were made mandatory.
  • Rules for how clients and servers specify which hash and signature algorithms they will accept were made clearer.

The changes in TLS 1.2 underscore how TLS is a complex collection of cryptographic functions and rules for how they are to be used. As with all security, these individual functions are improved over time, if only by using larger values to increase the cost of brute force attacks.

Major changes in TLS 1.3

The authors of TLS 1.3, released as RFC 8446 in August 2018, took a more comprehensive look at the TLS design and changed some of the protocol to improve performance of the algorithms and the organization and logic of the security features. In the section above on the TLS handshake, I described the 1.3 version of it. The 1.2 version is much more complicated and longer.

So 1.3 is much better, but it is new and different. As a result, implementation has taken a while. As of late 2018, only a few implementations have been released. Some of these, when released, exposed incompatibilities with significant products in the wild, generally causing the TLS authors to not make 1.3 the default version. Important vendors like Apple and Microsoft have not yet released TLS 1.3 implementations.

In terms of security, TLS 1.3 removes more old and weak algorithms, even whole classes of algorithms. It mandates support for perfect forward secrecy—which protects past session data from compromise in the event of a future key compromise—adds a session hash, and adds new, stronger algorithms for MAC, digital signatures, and key exchange.

TLS for the long haul

I’ve written before about how experts are concerned about the possibility that asymmetric encryption algorithms, such as those used in TLS, will become easily crackable in an era of quantum computers. Even though this prospect is many years away, there are experts at the National Institute of Standards and Technology working on new algorithms that will survive attacks by quantum cracking.

TLS gets this level of attention because it and the PKI on which it relies are, if this can be said of any algorithm, critical infrastructure. Without TLS, our financial data, our medical data, military communications, and everything else that is important and sensitive would be exposed to the world. Just about everyone, whether they know it or not, needs TLS to work.