Transport Layer Security, or TLS, is one of the more popular protocols that implement encryption and authentication.

TLS provides for encryption of Application Layer data, as well as authentication of the client and server transferring that data. URLs with the scheme https (as opposed to http) use TLS to transfer data. Since TLS encrypts session IDs when it sends them, they are of no use to an unauthenticated user who hijacks them.

The TLS PDU

Despite its name, “Transport Layer Security” doesn’t exactly run in the Transport layer. It is actually a sort of sub-layer that runs between the Transport and Application layers. It has a PDU of its own (called the TLS Record Protocol) that encapsulates an Application Layer payload and is itself encapsulated at the Transport Layer level by a TCP segment.

A TLS PDU looks like this:

1. Content type. Identifies what type of message is in the PDU: change_cipher_spec, alert, handshake or application_data. The alert content type is to notify of transmission errors, expired or revoked CAs, and so on.
2. TLS version.
3. Length. The length, in bytes, of the following payload.
4. Payload, or application data PDU.
5. Message Authentication Code, or MAC code. This code is used to determine whether or not a message has been altered in transit. (The MAC code is not related to the Media Access Control address, or MAC address. The only thing the two have in common is that they share the same acronym. For more on MAC addresses, see Chapter 5: Transmitting Data Frames on the Link Layer.)
6. Padding. Forces size uniformity in PDUs, which prevents attacks based on differing sizes of PDUs.

How TLS Verifies Digital Certificates

TLS requires a server to send a DC to be verified by a client. The server may optionally request a DC from the client as well. The basic DC verification process has these steps:

1. A sender sends a DC to a recipient, along with a hashed version of the DC’s tbsCertificate field.
2. The recipient decrypts the DS, using the public key contained in the DC. The result of this should be the tbsCertificate field in plaintext.
3. The recipient hashes the result of this decryption and compares it to the hashed version of the tbsCertificiate field.
4. If they are equivalent (and some other checks pass, for example whether a certificate has been revoked or has expired), then the DC is authenticated.

This process happens for each CA in the server’s chain, up to the root CA. If the CAs can authenticate all the certificates in the chain, the DC passes as verified.

Next, we’ll see how TLS transmits encrypted and authenticated data.