Skip to content
Docs
Theory, Analysis
TLS, SSL

TLS, SSL

This article analyzes TLS (Transport Layer Security) / SSL (Secure Socket Layer).

1. TLS (Transport Layer Security) / SSL (Secure Socket Layer)

TLS (Transport Layer Security) / SSL (Secure Socket Layer) is a standard security Protocol that operates on top of TCP. HTTPS is a representative Protocol that operates on top of TLS/SSL. TLS/SSL uses both symmetric keys and asymmetric keys to reduce the Overhead of RSA, the algorithm used for asymmetric keys. The Client encrypts the symmetric key to be used for Data encryption with the Server’s asymmetric Public Key and sends it to the Server. After that, the Server obtains the symmetric key with its asymmetric Private Key and exchanges Data with the Client using the obtained symmetric key. Since the asymmetric key is used only when encrypting/decrypting the symmetric key, the RSA Overhead caused by using the asymmetric key can be minimized.

1.1. Handshake

[Figure 1] TLS/SSL Handshake Process

[Figure 1] TLS/SSL Handshake Process

[Figure 1] shows the first Handshake process of TLS/SSL.

  • 1 : The Client sends a Client Hello Message to the Server. This Client Hello Message includes the TLS/SSL Versions supported by the Client, a Random value generated by the Client, and the list of Cipher Suites supported by the Client. A Cipher Suite includes information such as the Protocol, Key exchange method, and encryption method used for TLS/SSL communication.
  • 2 : In response to the Client Hello, the Server sends the highest TLS/SSL Version supported by both the Server and the Client, a Random value generated by the Server, a Session ID issued by the Server, and the Cipher Suite selected by the Server from the Client’s Cipher Suite List.
  • 3,6 : The Server sends the Server Certificate to the Client and sends a Server hello done Message.
  • 8 : The Client verifies whether the signature of the Server Certificate is valid. If the signature is valid, the Client encrypts the Pre-master Secret, which consists of the Protocol Version and a Random value, using the Server Public Key included in the Server Certificate, and sends it to the Server. The Server and the Client each obtain the Master Secret using the Random value generated by the Client, the Random value generated by the Server, and the Pre-master Secret.
  • 10, 11 : The Client sends Change Cipher Spec set to 1 and sends Finish to end the Handshake.
  • 12, 13 : The Server sends Change Cipher Spec set to 1 and sends Finish to end the Handshake.
  • 14 : The Server and the Client create a Session Key based on the Master Secret and encrypt Packets using the Session Key as a symmetric key.

The following describes the Optional steps.

  • 4 : If the Server Certificate does not include a Server Public Key, the Server sends a temporary key that replaces the Server Public Key.
  • 5,7,9 (mTLS) : The Server can request a Client Certificate during the Handshake. The Client that receives the Certificate request sends the Client Certificate to the Server. The Client also signs the Hash value of the Handshake Messages so far with the Client Private Key, includes the result in a Client Certificate Verify Message, and sends it to the Server. The Server can verify whether the Client is legitimate through the Client Public Key obtained from the Client Certificate, the signature of the Handshake Messages received from the Client, and the Handshake Messages themselves. When the Handshake process includes this step in which the Server verifies the Client, it is called mTLS (Mutual TLS).

1.2. Resumed Session

[Figure 2] TLS/SSL Session Resumption

[Figure 2] TLS/SSL Session Resumption

[Figure 2] shows the simplified Handshake process performed when the Client connects to a Session whose Handshake was previously completed. The Client must store the previous Session ID and the Master Secret used in the previous Session. The Server must also store the previous Session ID and the Master Secret used in the previous Session.

  • 1 : The Client sends a Client Hello Message to the Server. The Client sends the TLS/SSL Versions supported by the Client, a Random value generated by the Client, and the list of Cipher Suites supported by the Client, which were sent in the first Handshake process, together with the Session ID received in the previous Handshake process, as they are to the Server.
  • 2 : The Server checks the Session ID. If the Session ID is valid, the Server sends the same Session ID to the Client to inform the Client that the Session is valid. If the Session ID is not valid, the Server sends a different Session ID and the Handshake proceeds through the same process as the first Handshake.
  • 3,4,5,6 : The Client and the Server send Change Cipher Spec and Finish to complete the Handshake.
  • 14 : The Server and the Client create a Session Key based on the Master Secret and encrypt Packets using the Session Key as a symmetric key.

1.3. CA (Certificate Authority), Certificate

[Figure 3] Certificate Tree

[Figure 3] Certificate Tree

A CA (Certificate Authority) is an organization that issues and certifies Certificates. Among CAs, the CA that issues the top-level Certificate is called the Root CA, and the Certificate issued by the Root CA is called the Root Certificate. Since the Root Certificate is signed by itself, it is also a Self-signed Certificate. Root Certificates are installed in web browsers by default.

When a Certificate issued by a subordinate CA is signed using the Root CA’s Private Key, trust is also granted to the subordinate CA’s Certificate because of the trust in the Root Certificate. In addition, the trusted subordinate CA’s Private Key can be used to grant trust to a Certificate issued by yet another subordinate CA. In this way, the relationship between Certificates forms a Tree structure with the Root Certificate as the Root. Therefore, the closer a Certificate is to a Leaf of the Tree, the more upper-level Certificates it requires.

2. References

TLS SNITLS, SSL Certificate