Transport Layer Security Deep Dive

Posted on January 25, 2020

An attempt to provide a comprehensive overview of function, development and recommended parameters for deployment of Secure Sockets Layer (SSL) and Transport Layer Security (TLS) respectively…

Principle of TLS Operation

The TLS provides secure communication using an automated process of negotiation between two communicating parties, at the beginning of which is a phase called a Handshake. The message exchange and the number of phases within the TLS Handshake differs according to the TLS version used.

The TLS Session (also called a “tunnel”) is established in:

four phases when TLS 1.2 or older version is used (also called a “four-way handshake”),
three phases when TLS 1.3 is used.

Furthermore, the protocol defines the format and order of exchange of messages (see the appropriate sections of the RFC 5246 and the RFC 8446 for more details). The number of and type of messages differs according to the requests sent by either the client or server side. For illustrative purposes, the difference between the TLS 1.2 and 1.3 can be captured by Wireshark).

Note: In the following text, the message title is denoted using bold font, the message flow direction using the angle bracket (client to server: C>S, server to client: C<S).

TLS 1.2

Client negotiation phase (C>S)
- ClientHello
  - The message content is as follows:
    - the highest supported version of the TLS,
    - a Client Random Number (generated by the client),
    - a list of proposed Cipher Suites,
    - a list of proposed compression methods.
  - Session ID in case of resuming a session.
  - In case of Application-Layer Protocol Negotiation (ALPN), defined in the RFC 7301, the message contains also supported application layer protocols.
Server negotiation phase (C<S)
- ServerHello
  - The message content is as follows:
    - selected protocol version (the highest supported by both communicating parties),
    - a Server Random Number (generated by the server),
    - a list of Cipher Suites“,
    - a list of compression methods.
  - Session ID in case of resuming a session.
- Certificate (sent by the server optionally)
- ServerKeyExchange
  - Sent by the server optionally.
  - Sent always in case of using Diffie-Hellman-based cipher suites.
- ServerHelloDone (The negotiation phase was completed by the server.)
Client authentication phase (C>S)
- ClientKeyExchange,
  - Based on the cipher suites used, the message contains the following:
    - the Pre-Master Secret key, which is encrypted using the public key acquired as part of the server sent certificate,
    - the public key,
    - or nothing.
  - The random numbers and the Pre-Master Secret are used to calculate a mutual password called the Master Secret, which is consequently used to derive other keys used for the particular session.
- ChangeCipherSpec (A message with Content Type set to 20.)
- Finished (An encrypted and authenticated message, which contains a fingerprint and a MAC of the previous message and which is verified and deciphered by the server.)
Server authentication phase (C<S)
- ChangeCipherSpec (A message analogical to the message used in phase 3.)
- Finished (A message analogical to the message used in phase 3, which is verified and decrypted by the client.)

The Handshake process is now complete and communication of the application layer protocol is now possible (the Content Type is set to 23). The application layer messages will be also authenticated and (optionally) encrypted as in the Finished message (the Content Type value is set to 25 otherwise).

Note: During the negotiation process, the client can be authenticated as well. More information can be found in the appropriate section of the RFC 5246.

TLS 1.3

Keys exchange phase (C>S)
- ClientHello, SupportedCipherSuites, GuessesKeyAgreementProtocol, KeyShare
- The main differences when compared to the TLS 1.2 are the following:
  - The client tries to guess which Key Agreement Protocol will be used for key negotiation.
  - According to the method selected in the previous step, the client sends an appropriate shared key call Key Share“.
Server parameters phase (C<S)
- ServerHello, KeyAgreementProtocol, KeyShare, ServerFinished
- The reply contains the following parameters:
  - The Key Agreement Protocol value selected by the server.
  - The Key Share of the server.
- When compared to the TLS 1.2, this reply is sent as the second message to ensure a considerable decrease in delay, called Zero Round-Trip Time (0-RTT).
Authentication phase (C>S)
- ClientFinished
- Before being sent, the client performs the following operations:
  - Server certification verification.
  - Keys generation.

Note: The same as with the TLS 1.2, the client can be also optionally authenticated. More information can be found in the appropriate section of the RFC 8446. In the 0-RTT mode, the decrease can be in hundreds of milliseconds and approximately 20% of the whole Handshake traffic.

The TLS 1.3 does not support the following deprecated and obsolete algorithms:

using the DES and 3DES block ciphers,
using the RC4 stream cipher,
using the RSA cryptosystem for key exchange,
using the MD5 and SHA-1 hash functions,
selected Diffie-Hellman groups used for key exchange (CVE-2016-0701),
all block ciphers working in the CBC mode,
all export-strength ciphers, in relationship to the FREAK and LogJam attacks, i.e. intentionally weakened US algorithms (reduced key space).

On the other hand, the TLS 1.3 does not solve all of the previous problems. In fact, the following two remain unsolved:

Does not support full forward secrecy (FFS). After capturing Session Tickets, the attacker can decipher the whole 0-RTT client communication. Some progress has been made, as the TLS 1.2 does not support the FFS at all.
Does not guarantee complete prevention of replay attacks. After capturing the encrypted 0-RTT data, the attacker can spoof client and pretend to be the client in from of the server, as there is no way for the server to verify the client.

A Little Bit of Cryptography Theory

There exist two modes of encryption:

Block mode – messages are divided into blocks/chunks (usually 8 bytes / 64 bits), which are encrypted together.
Stream mode – messages are encrypted bit by bit, when the XOR operation is applied on each bit of key and each bit of plaintext (PT).

A PT block (a block of data) can be encrypted in many ways. The NIST SP 800-38A defines the following Block Cipher Modes of Operation:

Electronic Codebook (ECB)
- The ECB simply encrypts a block of PT using a block of key.
- Pros: The encryption as well as the decryption process can be parallelised.
- Cons: The same PT encrypts (transforms) into the same ciphertext (CT) – deterministic encryption. Therefore, a codebook between PT and CT pairs can be acquired. The fact that the whole CT block can be spoofed, renders the ECB useless.
Cipher Block Chaining (CBC)
- The CBC introduces randomness by concatenating a block of PT with an initialisation vector (IV) using XOR, the product is then encrypted with a block of key. The CT output is then chained with the PT (instead of the IV). The IV does not need to be kept secret, but it must be used only once, also called as the nonce (number used once).
- Pros: A bit error is automatically eliminated during decryption (also called as the self-recovering feature of the CBC). Moreover, the decryption process can be parallelised.
- Cons: Encryption cannot be parallelised (the next state always depends on the previous one) and changes in CT affect the PT.
Cipher Feedback (CFB)
- The CFB works in the stream mode, i.e., it encrypts each bit after bit. The IV is encrypted with the key and the output is XORed with bits of the PT. The CT is used as feedback (to be used instead of the IV).
- Pros: The encryption and decryption processes are identical, but only the decryption can be parallelised, as the keystream is a function (product) of the CT.
- Cons: The encryption process cannot be parallelised due to the feedback.
Output Feedback (OFB)
- The OFB works also in the stream mode. The IV is also encrypted using the key, but this product is not only XORed with the bits of the PT, but also used as feedback (to be used instead of the IV).
- Pros: The decryption process can be performed before receiving the CT offline (the IV and the key are known) and this product consequently XOR with the received CT.
- Cons: The encryption or the decryption process cannot be parallelised.
Counter (CTR)
- The Counter is the last representative of the stream mode, which was designed by Diffie and Hellman in 1979. It is very similar to the CFB and the OFB. However, the counter value is used to generate the key stream. The counter value should be changed with each change of the the key stream. It is usually performed by using a random value of the IV (shorter block than the PT), which is expanded to the PT length by the value of the counter (which is all zeros).
- Pros: The encryption or the decryption process can be parallelised.
- Cons: Setting up the default counter value as zeros may introduce a security risk.

Proven by history, the usage of encryption algorithms which do not concurrently support confidentiality, integrity and availability (the CIA triad) is very dangerous. Therefore, authenticated modes were proposed, or more precisely Authenticated Encryption with Associated Data (AEAD) were formalised in the international standard ISO/IEC 19772:2009, which defines the following mechanisms:

Integrity Aware Parallelizable Mode (IAPM)
- Increases efficiency and throughput by providing parallel data processing.
- Although, it is usually replaced by the GCM today, it was the first method to provide confidentiality and integrity in a single step.
Offset Codebook Mode (OCB) v 2.0
- Based on IAPM, there are three versions: OCB1, OCB2 and OCB3, while the associated data support was included in version 2 (more details in the ISO/IEC 19772:2009).
- OCB3 is defined in the RFC 7253 and introduces minor performance improvements when compared to the OCB2.
- When compared to the CBC, the OCB provides a minimal overhead.
- When compared to the CCM, which provides similar functionality, the OCB requires twice as less encryption operations for a single message block (the amount of operations of associated data is the same).
Key Wrap
- The “Key Wrap” problem posed by the NIST, i.e. to provide a more efficient algorithm which would provide additional functions (such as resilience to operator error and low-quality random number generators), was addressed by several proposals.
- The American Standards Committee ANSX9.102 evaluated, selected and approved the following specifications:
  1. AES Key Wrap (AESKW).
  2. Triple-DES Key Wrap (TDKW).
  3. AKW1 to provide data confidentiality even in case of the adaptive chosen-ciphertext attack.
  4. AKW2 to provide security against weaker attacks, such as the known-plaintext attack (typical for the ATM/POS networks).
Counter with CBC-MAC (CCM)
- Designed by several employees of the RSA Laboratories.
- Pros: It requires two block cipher operations for each CT block and block of authenticated text (message), and one operation for authenticated encryption with associated data.
- Cons: The length of the PT (and associated data) must be known in advance. The associated data can be processed only after the message was processed.
- Usage: In the IEEE 802.11i (known as the CCMP/WPA2), IPsec, TLS 1.2 etc.
Encrypt-then-authenticate-then-translate (EAX)
- Also, designed to replace the CCM, since it is easier and more efficient.
- Operates in the CTR mode and authentication is provided by the One-key MAC (OMAC), as per the NIST SP 800-38B.
- The algorithm uses nonce and requires two iterations to provide authenticated encryption of PT (message).
- Pros: Supports any message length, simplicity and efficiency when compared to the CTR.
- Usage: The ANSI C12.22 (and RFC 6142) defines a derived version called the EAXprime (EAX′) to transfer data from smart meters used in Smart Grids, IoT etc.
Galois/Counter Mode (GCM)
- Designed as an improvement of the CWC mode, defined in the NIST SP 800-38D.
- Operates with a 128-bit block of input data, while the authentication is provided by the Galois Message Authentication Code (GMAC) and IVs can be of any length.
- Pros: efficiency and performance, which was the cause of broad acceptance and compatibility across systems. Furthermore, the key-feature is the ease of parallel-computation of the Galois field multiplication used for authentication.
- Usage: In Ethernet security – called the MACsec (IEEE 802.1AE), wireless security of the WiGig (IEEE 802.11ad), IPsec (RFC 4301 to RFC 4309), SSH (RFC 4251 až RFC 4256), OpenVPN and of course, the TLS 1.2 and newer.

Other options just briefly:

Carter-Wegman + CTR mode (CWC)
- Combines the CTR mode (encryption) with efficient polynomial Carter–Wegman MAC (authentication).
- More information can be found in the original publication or the IETF draft.
Sophie Germain Counter Mode (SGCM)
- A GCM variant, which uses modular arithmetic in GF(p) with a corresponding Sophie Germain prime instead of the binary field GF(2^128).
- More information can be found in the original publication.

When comparing individual schemes, it can be concluded that the most versatile authenticated block cipher mode of operation is the GSM (see Tab. 1).

Algorithm	CCM	EAX	CWC	GCM
Provable secure	Y	Y	Y	Y
Unpatented	Y	Y	Y	Y
Any length nonce	N	Y	N	Y
One key	Y	Y	Y	Y
On-line	N	Y	Y	Y
Preprocess static headers/AD	N	Y	Y	Y
Fully parallelisable	N	N	Y	Y
Preservers alignment	N	Y	Y	Y
Fully specified	Y	Y	Y	Y

Tab. 1: A Comparison of Authentication Schemes (source)

Further interesting literature to study:

M. Bellare, P. Rogaway, and D. Wagner. A conventional authenticated-encryption mode, 2003.
P. Švenda. Basic comparison of Modes for Authenticated-Encryption, 2004.

Conclusion

Knowing the necessary prerequisites as well as being familiar with the elementary principles of cryptography, it may be interesting to continue to the Currently Known Vulnerabilities of the TLS.

Tags: #TLS #SSL #security #RSA #Diffie-Hellman