In the last article HTTPS detail 1, I have introduced the detailed principle of HTTPS and communication process, but the total feeling is missing something, should be less targeted introduction to the security layer, so this article is a supplement to HTTPS detail 1. Remember this picture.

The difference between HTTPS and HTTP

Obviously, the biggest difference between HTTPS and HTTP is the addition of Secure Sockets Layer (SSL) or Transport Layer Security (TLS). This security layer ensures the security of the communication between the two parties on the Internet. How does this security layer work, and what is the SSL/TLS handshake process? This article will answer these questions one by one.

1. Concepts of SSL/TLS and SSL/TLS handshake

SSL and TLS provide identification and authentication channels for communication parties to ensure communication confidentiality and data integrity. The TLS protocol evolved from Netscape SSL 3.0, but the two protocols are not compatible. SSL has been replaced by TLS, so TLS is referred to as the security layer below. The TLS handshake is the process of starting HTTPS communication, similar to the three-way handshake used to establish a TCP connection. During the TLS handshake, communication parties exchange messages to verify each other, confirm each other, and establish the encryption algorithm they want to use as well as the session key (the key used for symmetric encryption). It can be said that the TLS handshake is a fundamental part of HTTPS communication.

2. What happens during TLS handshake

We already know that the purpose of a TLS handshake is to establish a secure connection, so what are the two parties doing in the process? Here are the answers:

  • Agree on TLS versions to be used for communication between the parties (e.g. TLS1.0, 1.2, 1.3, etc.);
  • Determine the password combinations to be used by both parties;
  • The client authenticates the server through a digital signature on the server’s public key and digital certificate (described in the previous article).
  • Generates a session key that will be used for symmetric encryption after the handshake ends.

3. TLS handshake details

Here is the TLS handshake:

SSL/TLS handshake details

  1. “Client Hello” message: The client sends a “Client Hello” message to the server to initiate a handshake request. This message contains TLS versions supported by the client and password combinations for the server to select, as well as a “Client Random” random string.
  2. “Server Hello” message: The server responds to the client with a “Server Hello” message containing a digital certificate, a password combination selected by the server, and a “Server Random” random string.
  3. Validation:The client authenticates the certificate sent by the server to ensure the identity of the peer. The authentication process can be divided into the following steps:
    1. Checking digital signatures
    2. Validate certificate chains (this concept is explained below)
    3. Check the validity of the certificate
    4. Check the revocation status of the certificate (revocation means the certificate is invalid)
  4. “Premaster secret” string: The client sends the server another random string “premaster secret”, which is encrypted by the server’s public key and can only be decrypted by the corresponding private key.
  5. Use private key: The server uses private key to decrypt “premaster secret”.
  6. Generating a shared KEY: Both the client and server use Client Random, Server Random, and Premaster Secret, and use the same algorithm to generate the same shared KEY.
  7. Ready: The client sends a FINISHED message encrypted with the shared KEY.
  8. Ready: The server sends a FINISHED message encrypted with the shared KEY.
  9. Secure communication: The handshake is completed and the two parties communicate securely using symmetric encryption.

4. Some important concepts in TLS handshake

  1. Digital Certificate: In asymmetric encrypted communication, the server sends the public key to the client. During this process, the public key is likely to be intercepted and replaced by a third party, who can then pretend to be the server and communicate with the client. This is known as a man in the middle attack. The solution to this problem is to exchange the public key through a trusted third party. In this way, the server does not send the public key directly to the client, but requires the trusted third party, namely the Certificate Authority (CA), to merge the public key into the digital Certificate. The server then sends the public key along with the certificate to the client, and the private key is kept by the server for security. A digital certificate generally contains the following contents:

    1. Public key of the certificate owner

    2. The proper name of the certificate owner

    3. Proper name of a certificate authority

    4. Start date of the certificate

    5. The expiration date of the certificate

    6. Version number of the certificate data format

    7. Serial number, which is the unique identifier assigned to the certificate by the certificate authority

      . .

  2. Digital signature: This concept is easy to understand, but it is similar to a person’s handwritten signature. It is used to ensure the legal identity of the data sender and the data content is not tampered with to ensure the integrity of the data. Unlike handwritten signatures, digital signatures change as text data changes. In the application scenario of digital certificates, the process for generating and verifying digital signatures is as follows:

    1. The server abstracts the certificate content (commonly used algorithm is SHA-256, etc.), obtains the abstract information, encrypts the abstract information with the private key, and obtains the digital signature
    2. The server sends the digital certificate along with the digital signature to the client
    3. The client decrypts the digital signature with the public key to obtain the summary information
    4. The client recalculates the certificate digest using the same information digest algorithm and compares the two digest information. If the two digest information are the same, the certificate is not tampered. Otherwise, certificate verification fails

  3. Certificate chain: A certificate chain, also known as a certificate path, is a list of certificates used to verify the legal identity of an entity. Specifically, in HTTPS communication, it is used to verify the legal identity of a server. The certificate chain is used to ensure the security of the root CA certificate. The middle layer can act as the proxy of the root certificate and serves as a buffer, as shown in the following figure. The certificate of station B is also taken as an example:

The certificate chain

The certificate chain starts with the root certificate, and the entity identified by each level of the certificate chain signs the certificate at the next level, while the root certificate itself is signed by the certificate authority. When verifying the certificate chain, the client must verify the digital signatures of all certificates in the chain until the root certificate is reached.

  1. Password specifications and password combinations (CipherSpecs and CipherSuites) :The algorithms used by the communication parties in the secure connection must comply with the password security protocol. CipherSpecs and CipherSuites define the combination of valid password algorithms. CipherSpecs is a combination of authentication encryption algorithms and message digest algorithms that both parties must agree to in order to communicate. CipherSuites defines the combination of encryption algorithms used in SSL/TLS secure connections. The combination includes three different algorithms:
    1. Key exchange and authentication algorithms used during the handshake (most commonly RSA)
    2. Encryption algorithm (used for symmetric encryption after handshake, AES, 3DES, etc.)
    3. Information digest algorithms (commonly used are SHA-256, SHA-1, MD5, etc.)

4, summarize

In this paper, the SSL/TLS handshake process is analyzed in detail, and several important concepts in the handshake process are added. For further information, check out CloudFlare’s and IBM’s websites, which are the main sources for this article. Visit more English websites, not only can improve posture, access to authoritative information, but also to improve a wave of English level, kill two birds with one stone, is not beautiful, I hope friends can develop such a good habit as soon as possible. That concludes the HTTPS details section, and I’ll see you in the next article.