TLS within the internet protocol stack – Transport Layer Security at a Glance
6.4.3 TLS within the internet protocol stack
TLS is located between the application layer and the transport layer in the internet protocol stack (a simplified version of the OSI protocol stack; see Figure 6.3).
Figure 6.3: TLS within the internet protocol stack
Because of this position, TLS provides security services (confidentiality, integrity, and authentication) to the application layer, whereas the original transport layer is unaffected (and unprotected) by TLS. TLS can therefore be seen as a secure version of the transport layer, in the sense that it adds security services to the services already offered by TCP, such as session management. In most cases, the application layer protocol is HTTP, but other protocols, such as SMTP, can be (and are) protected by TLS as well.
For correct verification of Message Authentication Codes (MACs) within TLS, it is crucial that no network packets are lost on the lower layers and that the receiver is able to reconstruct their correct order. While the connection-oriented TCP has the ability to detect packet loss and to re-order packets, the faster, but less reliable, UDP does not have this ability. Therefore TLS only works on top of TCP.
6.5 TLS version 1.2
While we are largely focusing on TLS version 1.3 in this book, it is also instructive to take a look at version 1.2. Firstly, there are still many TLS servers that do not support version 1.3. Secondly, and more importantly, TLS version 1.2 and TLS version 1.3 share the same basic architecture. In particular, the basic steps in the so-called handshake protocol are the same but can be better explained in the context of TLS version 1.2, which is a bit less dense than the TLS version 1.3 handshake.
6.5.1 Subprotocols in TLS version 1.2
TLS version 1.2 consists of several subprotocols. Their location within the internet protocol stack and their relation to each other are shown in Figure 6.4.
Figure 6.4: TLS subprotocols
- Handshake protocol: This protocol is invoked when the client and server meet for the first time or if they want to resume an earlier session. In the former case, they need to agree on a set of algorithms that protect the channel between them, agree on a shared secret, and authenticate each other. All this is organized by the handshake protocol. How it is done in detail is the main content of Part II, Shaking Hands of this book.
- Alert protocol: If something goes wrong during the handshake protocol or record protocol, the alert protocol provides a pre-defined error code that indicates what exactly the problem was. For example, code 20 stands forbad˙record˙mac, a record with an incorrect MAC, and code 43 stands forunsupported˙certificate.
- Change cipher spec protocol: This protocol consists of a single message with a pre-defined value that serves to signal a change in the ciphering strategy. It is usually displayed within the context of the handshake protocol, but it was defined as a separate protocol so that the message is not accidentally broken up into two records by the record protocol. Note that there is no change cipher spec protocol in TLS version 1.3 anymore, except when needed for backward compatibility.
- Application data: This protocol is basically a container for the application layer protocol being secured by TLS (e.g., HTTP).
- Record protocol: This subprotocol takes data from the higher-layer subprotocols (for example, Application data or the handshake protocol) and re-organizes them into chunks called records. These chunks are encrypted and integrity-protected by the record protocol and transferred to the lower layer protocol. How this is done in detail is described in Part III, Off the Record of this book.