After discussing the different protocols constituting TLS in the previous section, this article will focus on the ClientHello/ServerHello of the handshake protocol as being the fundamental part of TLS since it allows the negotiation of encryption algorithms.

The ClientHello contains a set of cryptographic suites that the client is ready to use during the session. The server is expected to select one of these, after comparison with the ones it supports and accepts to use. This selection affects the way in which the cryptographic keys will be used to protect the record packets exchanged after the Handshake, which in particular carry the application data. The procedure for negotiating the keys is itself modified according to the sequence adopted. The general form of a cryptographic sequence is:

*Protocol_Key Exchange Protocol_WITH_Symetric Encryption Algorithm_Encryption Mode_Hash Algorithm*

Each suite is a combination of the following cryptographic mechanisms:

**Key Exchange Protocol**: this is the key exchange mechanism, which specifies an exchange algorithm and possibly the signature algorithm used to authenticate the exchanges: RSA, ECDHE \ _RSA and PSK are some examples;**Symetric Encryption Algorithm:**Mechanisms for the confidentiality of data exchanged after handshake, defined as either the composition of an encryption algorithm and a hash function used in HMAC mode, such as AES_256_CBC_SHA384, or as an integral encryption mode , Also called combined mode, offering simultaneously encryption and integrity, such as AES_256_GCM;**Encryption Mode:**the block encryption mode used with the previous algorithm;**Hash Algorithm:**The hash algorithm used to ensure message integrity.

For example, the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 suite represents the association of the ECDHE_RSA key exchange mechanism with the integral encryption mode AES_256_GCM supplemented with SHA384 for the derivation of the secrets.

#### 1. Key Exchange Protocol:

All the key exchange protocols below make it possible to obtain a pre_master_secret, the master_secret is generated by the application of the PRF function, such as: *PRF (pre_master_secret; “mastersecret”; ClientHello.random + ServerHello.random)* Where PRF is the iterative hash function defined by the cryptographic sequence such that:

Where the sum indicates the concatenation, *A0 = seed, A(i) = HMAC_hash(secret, A(i-1))* and *n* is a function of the required output value. For the secret master, the size is 48 bytes or two iterations with P_SHA-256. From this secret, the session key is generated by the formula:

PRF(master secret, « keyexpansion », ClientHello.random + ServerHello.random)

Such as the concatenation of* key.mac.client, key.mac.server, key.encryption.client, key.encryption.server, IV.client, and IV.server*. This method is defined by RFC 5246.

There are several key exchange methods, some of which do not require server authentication. However, in the absence of this protection, the exchange of keys is exposed to attacks by middle man who could compromise the security of all exchanges. Therefore, server authentication is strongly recommended.

In the general case, the exchange of keys is based either on the asymmetric encryption of a secret using the public key of the server (RSA for example), or on the Diffie-Hellman algorithm in the cases the most common.

**Key exchange with Diffie-Hellman (DH):**

The key exchange based on DH is defined by the RFC2631, there are several variants like: Diffire-Hellman (DHE), Elliptic Curve Diffie-Hellman (ECDH), Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), Anonymos Diffie-Hellman (ADH).

DHE works in the following way: Public parameters of DH are exchanged, they can vary from one session to another which makes them harder to break by brute force. Here, to avoid the attack of the man in the middle, the server and the customer proves that it is they who have well generated the values of DH. To do this, there are different solutions:

- Sign the DH values with its private key (RSA, DSS, ECDSA).
- Authenticate DH exchange with a shared secret key (PSK)

**Key exchange with RSA:**

The algorithm then serves both in the KeyExchange step as well as in the authentication. The diagram below shows the exchange of keys with RSA.

Persistent Perfect Forward Secrecy (PFS) is a cryptographic property that ensures that the discovery by an opponent of a private key of a correspondent (long-term secret) does not compromise the timeliness of past communications. The use of RSA for key exchange does not provide PFS protection.

**Key exchange with Pre-Shared Key (PSK):**

PSK is an algorithm based on keys exchanged in advance defined by RFC 4279. It therefore suffers from the problem of the exchange of these keys via a secure channel. In practice, it is only very usable since it requires the customer to know these keys in advance, which is very rarely possible. When PSK is used for key exchange, the pre_master_key is formed as follows: If the PSK is N bytes, we start by concatenating a uint16 with the value of N, N zero bytes, a second uint16 with the value of N And the PSK. The diagram below shows the key exchange with PSK:

**Recommendations:**

- Authenticate the server to the exchange of keys: During a key exchange, the server must be authenticated by the client (in order to avoid attacks of the type MITM).
- The recommended key size for using RSA is 4096 bits.
- Privilege Diffie-Hellman Ephemeral which allows the use of temporary DH parameters signed by the master key (DHE with group sizes of 3072 bits or ECDHE with P-256 curves), to avoid attacks of the MITM type and ensure PFS.

#### 2. Symetric Encryption Algorithm:

The pre_master_key negotiated using the previous exchange is derived on both sides in a secret master, from which is derived in particular the symmetric encryption key used for the privacy protection of the exchanges that follow the negotiation phase.

**Recommendations:**

- Prefer encryption with AES-256 or AES-128.
- Use suites that implement block encryption algorithms such as Camellia.
- Triple DES should not be maintained. However, it is tolerated, provided that the associated encryption keys are renewed at least with each gigabyte of application data exchanged.
- DES, IDEA and RC4 are algorithms that are too weak to guarantee good security.

#### 3. Hash Algorithm:

This is the data protection mechanism, to prevent an attacker from modifying encrypted messages. Once the TLS session is established, each record packet sent is protected in integrity. For this purpose, HMAC is used with the hash function SHA1 or SHA2. When the cryptographic suite does not use an integral encryption mode, it is an integrity pattern calculated by the HMAC mode, which relies on a hash function.

The HMAC construction, proposed by Bellare, Canetti, and Krawczyk in 1996, is standardized and used in many protocols. We define HMAC (m) by:

Thus, the security guaranteed by the HMACs is equivalent to twice that guaranteed by a hash function.

**Recommendations:**

- The HMAC for authentication must be built using a SHA-2 representative: SHA-256 or SHA-384.
- The use of HMAC constructed using SHA-1 is tolerated. However, the use of SHA-1 alone is considered obsolete and should no longer be used.

#### 4. Encryption Mode:

There are several encryption modes for symmetric algorithms:

**CBC:** defined by the following scheme:

**CBC-HMAC:** This mode is a combination of CBC mode for encryption and HMAC for integrity. The calculation of the HMAC involves data encrypted with CBC in order to avoid information leaks: Such an extension is called encrypt_then_mac.

**GCM:** Galois / Counter Mode is a block encryption mode that uses a universal hash on a Galois binary field to provide authenticated encryption. It ensures confidentiality and authentication at the same time. The encryption operation authenticated by GCM comprises four entries: a secret key, an initialization vector (IV), a plaintext and an entry for additional authenticated data (AD). It has two outputs, an encrypted text whose length is identical to plain text, and an authentication tag (TAG). The GCM mode is defined by the following scheme:

**CCM (Counter-Mode / CBC-Mac):** As its name suggests, CCM mode combines the CBC-HMAC with a counter. These two primitives are applied in an “authenticated and then encrypted” way, that is to say that CBC-MAC is first calculated on the message to obtain a TAG tag. The message and the label are then encrypted using the counter mode (CTR). A key point is that the same encryption key can be used for both, provided that the counter values used in the encryption are not in collision with the initialization vector (IV) used in the authentication.

**recommendations:**

- Use modes that ensure encryption and integrity (authentication) such as GCM (only supported on TLS), CCM, CBC-HMAC.
- The CBC encryption mode is systematically degraded to Standard despite a perfect security in the case of a connection made from a modern browser.