TLS overview – Transport Layer Security at a Glance

6.4 TLS overview

The main task of the TLS protocol is to create a secure communication channel between two parties: server Alice and client Bob. The only thing that RFC 8446 assumes is a reliable, in-order data stream on the underlying transport layer. The two most widely used transport layer protocols are the Transport Control Protocol (TCP) and the User Datagram Protocol (UDP).

Thus, TCP lends itself to being a transport layer for TLS. In contrast, TLS doesn’t work with protocols such as UDP that provide no guarantees regarding message delivery or the sequence of the messages. There is, however, a closely related alternative to TLS called Datagram Transport Layer Security (DTLS), which works on top of UDP and offers similar security guarantees to TLS [149].

6.4.1 TLS terminology

RFC 8446 uses the following terms to specify TLS. A client is an endpoint that initiates a TLS connection. A server is an endpoint that receives the request from the client to establish a TLS connection. A handshake is the initial negotiation between the client and the server for establishing the parameters, including the secret keys, for their TLS connection. A sender is the endpoint transmitting the data over an established TLS connection. In the TLS context, this data is referred to as a TLS record. A receiver is an endpoint receiving the TLS records.

6.4.2 CIA triad in TLS

As we would expect, TLS provides confidentiality, integrity, and authentication. Once a secure channel is established at the beginning of the TLS protocol, data transmitted over this channel can only be decrypted by the endpoints. This is also the reason why you will often encounter the term end-to-end security in the context of TLS.

Note that by itself, TLS doesn’t hide the length of the transmitted data. This kind of information leakage where Eve learns metadata about the transmitted messages can compromise security. It represents an instance of traffic analysis attacks where the patterns of the communication – who communicates with whom, when, for how long, and so forth – are used to deduce secret information.

As an example, imagine a scenario where Bob can download three files of sufficiently different sizes, say 5 MB, 100 MB, and 500 MB, from a web server run by Alice. To determine which file Bob actually downloaded, Eve doesn’t have to break the encryption algorithm; she can deduce this by simply looking at the amount of data transmitted from Alice to Bob.

To avoid this weakness, TLS endpoints can apply an operation called padding. Padding simply appends dummy bytes to TLS messages to hide the length of their actual payload data and, as a result, increases protection against traffic analysis.

Because TLS was created for the web, it was designed with the client-server model in mind. Here, the primary risk is that an attacker impersonates a server such as an online shop or a bank. Therefore, the server side is always authenticated, but client-side authentication is optional (and very rarely used on the internet).

TLS 1.3 offers two types of authentication. Alice and Bob can use symmetric cryptography with a Pre-Shared Key (PSK) or asymmetric cryptography, in particular algorithms such as RSA, Elliptic Curve Digital Signature Algorithm (ECDSA), or Edwards-Curve Digital Signature Algorithm (EdDSA), which we will learn more about in the upcoming chapters.

Finally, to complete the CIA triad, the TLS protocol has mechanisms to ensure that the data sent over a TLS-secured channel cannot be modified by an attacker without detecting the modification.

TLS ensures confidentiality, integrity, and authentication even in the presence of an active attacker, Mallory. A list of these attacks, including examples, is given in RFC 3552, which, among other things, describes the so-called Internet Threat Model used by most IETF standards.

The TLS protocol is application-independent. In other words, higher-level protocols can be built on top of TLS. However, TLS does not specify how to add security on higher layers using TLS. As an example, the TLS standard does not specify how authentication certificates exchanged during the initial TLS phase should be interpreted by the application or a higher-layer protocol. These details are left to the designers of applications and protocols running on top of TLS.

Moreover, TLS V1.3 is not directly compatible with previous TLS versions. However, it should still be possible that a TLS V1.3 client can connect to a TLS V1.2 server and vice versa. As a result, TLS defines a mechanism for the endpoints to negotiate a common version of TLS (if there is one that is supported by both endpoints).