WWW
4 Mar 2023

How the Internet Works, Chapter 19
The Application Layer: How TLS Transmits Encrypted and Authenticated Data

by | posted in: How the Internet Works | 0

The TLS handshake

The process of securely exchanging symmetric keys is called a TLS handshake. The TLS handshake requires the Transport Layer to use TCP, and also requires the TCP handshake to have already taken place.

TLS Handshake Key exchange algorithms

Different key exchange algorithms have somewhat different TLS handshake steps. These are the steps in a TLS handshake using the popular RSA algorithm:

  1. Immediately after receiving the TCP ACK segment from the server, the client sends a ClientHello message. This message contains at a minimum the highest supported version of TLS that the client supports, a random number, and the cipher suites that the client can support.
  2. The server responds with a ServerHello message. This message contains at a minimum the version of TLS that the exchange will use (its highest version or the highest version in the ClientHello message, whichever is lower), a random number, and a cipher suite that it supports from the set the client sends.
  3. The server sends its DC chain to the client.
  4. The server sends a ServerHelloDone message to the client.
  5. The client verifies the server’s DC chain. (To see how, see How TLS Verifies Digital Certificates in the previous article.)
  6. The client sends a ClientKeyExchange message. This message includes a random byte string encrypted with the server’s public key. This string is called the premaster secret.
  7. Both client and server compute the symmetric key based on the premaster secret and the random numbers they received in steps 1 and 2. This key is called the master secret.
  8. The client sends a ChangeCipherSpec message, notifying the server that it will send subsequent messages using the master secret key. It then sends a Finished message, which is the first message that uses the master secret key for encryption.
  9. The server sends a ChangeCipherSpec and Finished message to the client.
  10. Both client and server use a formula to validate the Finished messages that they have received.

After these steps successfully complete, RSA performs certain calculations on the master secret key and symmetrically encrypted data transfer begins.

MAC codes

The MAC code determines whether a received message is the same as it was at its point of origin. MAC codes use the Server Write MAC and Client Write MAC keys for encryption, depending on whether the TLS PDU originates at the client or server.

These are the steps to create a MAC code:

  1. Sender creates a digest of the payload. This process involves taking a small portion of the data payload and running it through a hash function with a pre-agreed seed value. (The handshake chooses exactly which hash function from the cipher suites during authentication; see ServerHello above.)
  2. Sender encrypts the digest with the appropriate (client or server) write MAC key.

At the receiving end, the receiver:

  1. Decrypts the MAC code using the same key as in 2 above.
  2. Creates its own digest (using the mutually agreed-upon method) of the incoming data payload.
  3. Compares this digest with the one that came through in the TLS PDU.
  4. If the two digests are the same, the data hasn’t been altered in transit.

Session Keys

To reduce the possibility of a master secret being discovered, four separate keys, informally called session keys, are computed from it, and these are the keys that are actually used. The session keys are:

  1. Server Write Encryption
  2. Client Write Encryption
  3. Server Write MAC
  4. Client Write MAC

Both client and server have an identical set of these keys. Since they are symmetrical, each can be used for both encryption and decryption. As the names of these keys imply, the client and server actually use different keys to encrypt data, and they each use yet another key to encrypt MAC codes.

For example, the server encrypts data using the server write encryption key, and the client uses the same key to decrypt it. Encrypted traffic going the other way uses the client write key to both encrypt at the client and decrypt at the server. Similarly with the server write MAC and client write MAC keys, which encrypt and decrypt MAC codes.

Odds and Ends

This finishes the coverage of the four layers of TCP/IP. The remaining articles in the series take up various miscellaneous topics, starting with a brief history of HTTP and AJAX.

Chapter 19Chapter 20