TLS (Transport-Layer Security)

$ \def\ZZ{\mathbb{Z}} \def\GG{\mathbb{G}} \def\HH{\mathbb{H}} $

Overview

TLS is the mostly widely used cryptographic protocol for secure communications on the Internet.

The main purpose of TLS is to provide end-to-end security against an active, man-in-the-middle attacker.
Originally deployed (as SSL) in web browsers for https connections, TLS is now used as a general purpose provider of secure communications to all kinds of applications: e-commerce transactions, virtual private networks (VPN), Android and iOS mobile apps. In short, TLS is one of the most important real-world deployments of cryptography.

The main benefits of TLS is as follows:

Security
- Primarily, TLS provides data confidentiality using encryption. It also provides data integrity through message authentication codes.
- It also offers server authentication and, optionally, client authentication to prove the identities of parties engaged in secure communication.
- Additionally, it offers protection against man-in-the-middle attacks and replay attacks.
Ease of deployment
Because TLS is implemented beneath the application layer, most of its operations are completely invisible to the client. This allows the client to have little or no knowledge of secure communications and still be protected from attackers.

TLS Layer

The TLS security protocol is layered between the application protocol layer and TCP/IP layer, where it can secure and then send application data to the transport layer. Because it works between the application layer and the TCP/IP layer, TLS can support multiple application layer protocols.

The TLS protocol can be divided into two sub-layers.

Handshake layer.
The Handshake Layer again consists of three sub-protocols:

Handshake. This sub-protocol is used to establish a session key between the client and the server.
Change Cipher Spec. The Change Cipher Spec sub-protocol is used when the sender wants to change to a new set of keys. The key is computed from the information exchanged by the Handshake sub-protocol.
Alert. Alert messages are used to indicate a change in status or an error condition to the peer. Alerts are commonly sent when the connection is closed, an invalid message is received, a message cannot be decrypted, or the user cancels the operation.

Fig 1. TLS Protocol Layers

Record Layer.
The protocol at the record layer receives and encrypts data from the application layer and delivers it to the Transport Layer. Received data are decrypted, verified, decompressed, and reassembled, and then delivered to the application layer.

TLS Protocol

TLS protocol consists of two steps.

Step 1: Handshake protocol. The client and server establish a shared secret key.
Step 2: Record protocol. Both parties exchange the data using the secret key.

Fig 2. Two steps of TLS

Handshake Protocol

When a client connects a server, both parties need to establish a shared private key (session key) under which data are to be encrypted. Moreover, the server show its certificate to authenticate itself to the client. The detailed procedure is as follows:

1. First Client Message to Sever

Client Hello. The client initiates a session by sending a Client Hello message to the server. The Client Hello message contains:
- Version Number. The version number for TLS v1.0 is 3.1.
- Randomly Generated Data. It will ultimately be used with the server random value $ r_C $ to generate a master secret from which the encryption keys will be derived.
- Session Identification (if any). The sessionID is included to enable the client to resume a previous session for efficiency.
- Cipher Suite. The list of cipher suites available on the client. An example of a cipher suite is TLS_RSA_WITH_AES_256_CBC_SHA256, where TLS is the protocol version, RSA is the algorithm that will be used for the key exchange, AES_256_CBC is the encryption algorithm, and SHA256 is the hash function.
- Compression Algorithm.

2. Server Response to Client

Server Hello. The server responds with a Server Hello message. The Server Hello message includes:
- Version Number. The server sends the highest version number supported by both sides.
- Randomly Generated Data. It's a random number $ r_S $ that will be ultimately used with the client random value to generate a master secret from which the encryption keys will be derived.
- Session Identification (if any). This can be one of three choices: New session ID, Resumed Session ID (from the client hello), Null (new session not to be reused in the future).
- Cipher Suite. The server will choose the strongest cipher that both the client and server support. If there are no cipher suites that both parties support, the session is ended with a “"handshake failure" alert.
- Compression Algorithm.
Certificate. The server sends its certificate to the client. The server certificate contains the server's public key. The client also checks the name of the server in the certificate to verify that it matches the name the client used to connect.
Server Key Exchange. This is an optional step executed when the server's certificate does not have contain RSA public encryption key, so both parties should perform DH key exchange protocol.
Client Certificate Request. This is an optional step in which the server requests authentication of the client.
Server Hello Done. This message indicates that the server is finished and awaiting a response from the client.

3. Client Response to Server

Client Certificate. If the server sent a Client Certificate Request, the client sends its certificate to the server for client authentication.
Client Key Exchange. The client first computes the pre-master secret $ PMS $ as follows:
- If the server has RSA public key, the client randomly selects a pre-master secret and sends it encrypted under the RSA public key. This encryption is included in included in included in included in included in included in included in included in the Client Key Exchange message.
- Otherwise, the client sends DH key exchange message (in the Client Key Exchange message). The pre-master secret is the result of DH key exchange.
Both parties will compute the master secret as follows: \[ MS = PRF_{PMS}( r_C \| r_S). \] Here, PRF stands for a pseudorandom function.
- AES is an example of PRF.
- Since PMS is hidden from the adversary, MS will be completely random to the adversary even if $r_C$ and $r_S$ are revealed to the public.
- The benefit of using PRF is that the server and client can use the same PMS in the other sessions to agree on a new master secret $MS'$ by using a different random $r'_C$ and $r'_S$.
Then, they finally derive the session keys from it. Fig 3. explains how session keys are established.

Fig 3. Establishing a session key
Certificate Verify. This message is sent only if the client previously sent a Client Certificate message. The client authenticates itself to server using its private key to sign all the messages up to this point.
Change Cipher Spec. This message is a one-byte message, notifying the server that the client will begin encrypting messages.
Client Finished. This message is a MAC tag on the hash of the entire conversation to provide further authentication of the client.

4. Server Final Response to Client

Change Cipher Spec Message. This message notifies the client that the server will begin encrypting messages with the keys just negotiated.
Server Finished Message. This message is a MAC tag on the hash of the entire exchange to this point.

Record Protocol

The record protocol receives the data from the application layer. In particular,

The protocol fragments the data into blocks or reassembles fragmented data into its original structure.
It numbers the sequence of data blocks in the message to protect against attacks that attempt to reorder data.
It compresses or decompresses the data using the compression algorithm negotiated in the handshake protocol.
It encrypts or decrypts the data using the encryption keys and cryptographic algorithm negotiated during the handshake protocol.
Applies an HMAC to outgoing data. Computes the HMAC and verifies that it is identical to the value transmitted in order to check data integrity when a message is received.

Fig 4. Record protocol

Example: Capture Packets

FREAK Attack (2015)

FREAK ("Factoring RSA Export Keys") is a security exploit of a cryptographic weakness in the TLS protocols introduced decades earlier for compliance with U.S. cryptography export regulations. These involved limiting exportable software to use only public key pairs with RSA moduli of 512 bits or less (so-called RSA_EXPORT keys), with the intention of allowing them to be broken easily by the NSA, but not by other organizations with lesser computing resources. However, by 2015, increases in computing power meant that they could be broken by anyone with access to relatively modest computing resources, using as little as $100 of cloud computing services.

Combined with the ability of a man-in-the-middle to manipulate the initial cipher suite negotiation between the endpoints in the connection, this meant that the adeversary, with only a modest amount of computation, could break the security of any website that allowed the use of 512-bit export-grade keys. In particular:

Your browser starts to connect to an HTTPS website, asking to use a strong cipher.
The attacker intercepts this request and replaces it with one asking to use weak "export-grade" encryption.
The server gets this modified request and responds to your browser with an export-grade encryption key.
Your browser doesn't notice the key it got is weaker than the one it asked for, and finishes setting up the SSL session using this weak key.
The attacker can now record your session and break the encryption on it in a matter of minutes to hours, or if the server re-uses keys (most of them do), use a previous break to read (and potentially modify) your traffic as it goes by.

Other attacks

Similar ideas are applied to subsequent attacks.

Logjam attacks. Downgrade the security of Diffie-Hellman key exchange protocol.
Drown attack. Downgrade the TLS protocol to SSLv2.
SLOTH attack. Have the protocol use insecure hash function (MD5). They attacked the second-preimage resistance of MD5.