TLS Protocols (1/3)

Azmi Sbai Etude - Recherche

Secure Socket Layer (SSL) is a protocol developed by Netscape since 1994 that allows the establishment of a secure (encrypted, integral and authenticated) connection. Version 3 dates back to 1995 and is the latest. Transport Layer Security (TLS) is the new version of SSL since the acquisition by the Internet Engeneering Task Force (IETF).

SSL / TLS is located above the transport layer of the TCP / IP model, so it has the advantage of being transparent to applications, such as HTTP (web client) or SMTP (mail). It can encrypt data, ensure the integrity of a message, and authenticate a client or server through the use of X509 certificates.

The main difference between SSL and TLS is that it uses stronger encryption algorithms and can support multiple extensions. SSL / TLS uses public key encryption for authentication and symmetric encryption for data exchange.

The TLS protocol is formed by 4 sub protocols:

  1. Handshake Protocol
  2. Record Protocol
  3. Change Cipher Spec Protocol (CCS)
  4. Alert Protocol

Handshake Protocol:

It is the protocol that governs the establishment of a connection between two entities of a network. It manages server and/or client authentication, negotiation of encryption algorithms and generation of symmetric keys. Below is a schematic representation of the sequence of the different messages exchanged.

1.Client Hello: the client initiates a request by sending a ClientHello message containing:

  • Version: the highest version of SSL/TLS the client can use;
  • Random: a 32-bit time stamp and a 28-byte random value generated by the client that will be used for key derivation;
  • CipherSuite: a list, in descending order of preference, of the cryptographic suites that the client supports;
  • Session ID: a number that identifies the connection; (optional)
  • Extensions: the various TLS extensions supported by the client: Server Name Indication (SNI), Signed Certificate Timestamp (SCT), Encrypt_then_MAC …

2.ServerHello: the server responds to the client with a ServerHello message that contains:

  • Version: the highest version of SSL/TLS the server can use;
  • Random: a 32-bit time stamp and a 28-byte random value;
  • Session ID: the identifier of the session that starts defined by the server;
  • CipherSuite: the cipher suite chosen for the session. The server selects the best sequence it knows from the list transmitted by the client;
  • Extensions: different TLS extensions supported by the server: FALLBACK_SCSV, Encrypt_then_MAC…

3.ServerCertificate (recommended): the server sends its X509 certificate that contains information about his public key.

4.ServerKeyExchange (recommended): in a ServerKeyExchange message, the server transmits an ephemeral exchange parameter signed using its private key (when exchanging keys based on RSA this step is optional).

5.ServerHelloDone: the server indicates that he is waiting for a response from the client.

6.ClientKeyExchange: After verifying the server certificate and the previous value, the client generates an ephemeral value that will be used to produce the keys used in the record protocol: In the case of RSA this key is sent to the encrypted server using his public key. In the case of DH this key is sent to the server encrypted with the private key of the client. Using this shared secret, the server and client generate four keys for the session that are not exchanged.

7.ChangeCipherSpec: The client reports the adoption of the negotiated suite with the server.

8.Finished: the cryptographic and security parameters were well taken into account. This message is encrypted and signed with the keys calculated previously.

Record Protocol:

It is the protocol that manages the transmission of encrypted data in a homogeneous form by encapsulating it, its objectives are:

  • Confidentiality: ensures that the content of the message can not be read by a third party: the data is encrypted using the keys produced during the negotiation.
  • Integrity and Authenticity: verifies the validity of the data transmitted, thanks to the HMAC signatures: this signature is also generated using the keys produced during the negotiation.
  • Encapsulation: Allows SSL/TLS data to be transmitted in a standardized manner and recognized in a homogeneous form.

The steps in the Record protocol encapsulation process are as follows:

  1. Segmentation: the data is cut into blocks of less than 16 kB;
  2. Compression: The data is compressed using the algorithm chosen during the negotiation. Note: starting with SSL v3.0, there is no more compression;
  3. MAC Signature: A signature of the data is generated using the MAC key (in case of using the MAC_then_encrypt extension);
  4. Encryption: The resulting packet is encrypted using the function defined during negotiation and key.encryption;
  5. Adding the header: The SSL/TLS header is added and the packet is passed to the bottom layer. It contains:
  • Content-Type: indicates the type of SSL and TLS packet contained in the record;
  • Major Version, Minor Version: Version numbers of the SSL/TLS protocol used;
  • Length: The SSL and TLS fragment size

Upon receipt of packets, the recipient checks the packet header, decrypts it, checks the HMAC field, and collects the individual blocks.

Change Cipher Spec Protocol:

This protocol contains a single 1-byte ChangeCipherSpec message and allows you to modify the encryption algorithms and establish new security parameters. It indicates to the Record protocol the change of the cryptographic suites.

Alert Protocol:

This protocol is used for error messages that can be sent to clients and servers. There are two kinds of warning messages:

  • The fatal error: causes the connection to stop
  • Warning: indicates unstable connection

We will see in a future article how cipher suites and certificate distribution work in the case of a global PKI.