Extended Brain Storage

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:

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

  1. 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.
  2. 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.)
  3. 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.)
  4. 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

  1. 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".
  2. 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).
  3. 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:

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

A Little Bit of Cryptography Theory

There exist two modes of encryption:

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:

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:

Other options just briefly:

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

Provable secureYYYY
Any length nonceNYNY
One keyYYYY
Preprocess static headers/ADNYYY
Fully parallelisableNNYY
Preservers alignmentNYYY
Fully specifiedYYYY

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

Further interesting literature to study:


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

⏴ Previous Post Next Post ⏵