“

Interviewer: Do you understand all the three versions of TLS handshake?

“

The TLS handshake process is quite complicated. As for the above questions, my previous understanding was very fragmentary and I did not answer them well in the interview. Now come down and write this article to deepen your understanding.

Specific combing is as follows:

  1. History of TLS.
  2. Details and summary of each version of the handshake.
  3. Extension.

History of SSL/TLS

As we know, HTTP is a plaintext transmission protocol, may be attacked by a third party, very insecure. Hence “HTTPS”.

The “S” indicates the SSL/TLS protocol, which can be expressed as follows: HTTPS = HTTP + SSL(TLS).

SSL refers to Secure Sockets Layer (SSL), which is the session Layer in the OSI seven-layer model.

For websites with TLS protocols, such as Nuggets, HTTPS/WWW will be automatically hidden in the Chrome address bar and replaced with 🔐 :

Here’s a partial history from authoritative documents:

  • In 1996, SSL3.0 was introduced and widely used (deprecated in 2015).

  • In 1999, SSL3.1 was standardized and updated to TLS1.0 (Transport Layer Security). So, TLS1.0 = SSL3.1.

  • The current mainstream version is TLS1.2 (released in 2008).

  • In the future, it could be the TLS1.3 era (released in 2018).

The TLS handshake

To understand the specific handshake process, first we need to know what is a handshake?

Handshake: Handshake is used as a precondition for communication. For example, a TCP Handshake is used to determine the receiving and sending capabilities of the two ends. A TLS handshake is used to verify identity and exchange information to generate a secret key for subsequent encrypted communication.

Using the Wireshark to capture packets, you can see that the TCP three-way handshake is used for all connections, regardless of whether the client and server use HTTP or TLS. However, the TLS four-way handshake is used after the TCP connection is established.

Therefore, seven handshakes are required for HTTPS’s first communication!

Detailed TCP learning materials can be found here: TCP Soul Questions, not the focus of this section.

This section analyzes the two main TLS handshake modes, namely, RSA handshake and DH handshake. Based on the DH handshake, the TLS1.3 handshake is developed and optimized to provide better security and performance. But before you do that, you need to understand some basic concepts (skip this if you already know them).

Basic concept

① Symmetric encryption

Encryption and decryption use the same string of key, common symmetric encryption algorithm: DES, AES, etc.

② Asymmetric encryption

Encryption and decryption use different keys, one as the public key and the other as the private key. Public key encrypted information, only the private key can decrypt. Conversely, only the public key can decrypt the information encrypted by the private key.

Common asymmetric encryption algorithms: RSA, ECC, etc.

RSA algorithm: Named after the initials of three scientists, RSA has been the most widely used “asymmetric encryption algorithm” in the computer networking world.

ECC is a “rising star” in asymmetric encryption. It is based on the mathematical problem of “elliptic curve discrete logarithm” and uses specific curve equations and basis points to generate public and private keys. The sub-algorithm ECDHE is used for key exchange and ECDSA is used for digital signature.

③ Hybrid encryption

In symmetric encryption algorithms, decryption can be done by holding the key. If the key you agreed to with a website is stolen in transit by a hacker, he can then decrypt the data he sends and receives at will, and the communication process is no longer confidential.

Asymmetric encryption algorithms need to be applied to complex mathematical operations, although the security is guaranteed, but the speed is very slow, several orders of magnitude worse than the symmetric encryption algorithm.

So TLS uses a “hybrid encryption” approach that takes advantage of many: asymmetric encryption algorithms are used at the beginning of communication to solve the key exchange problem. All subsequent communications use symmetric encryption.

Cryptosuite list

The encryption suite list is usually sent by the client for the server to select. View the list with OpenSSL:

➜ openssl ciphers -v ecdhe-rsa-aes256-GMM-sha384 tlsv1.2kx =ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD Ecdhe-ecdsa-aes256-gmc-sha384 tlsv1.2kx =ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 tlsv1.2kx =RSA Au=RSA Enc=AES(256) Mac=SHA256 ... . Cipher Suites(17 suites)Copy the code

The data above shows that the list comes with up to 17 encryption suites, which look like this when taken out individually:

It means:

  • TLSDuring the handshake process, useECDHEThe algorithm generates PRE_random.
  • Authentication (signature) useRSAAlgorithm.
  • A 128 – bitAESAlgorithm for symmetric encryption, in the process of symmetric encryption using mainstreamGCMGrouping mode allows the algorithm to encrypt plaintext of any length with a fixed-length key.
  • Finally, hash digest algorithm for data integrity check is adoptedSHA256Algorithm.

The digital certificate

Digital certificates generally serve two purposes:

  1. The server proves its identity to the browser, after all, the secret keys and even the server’s domain name can be forged.
  2. Pass the public key to the browser.

The certificate itself is granted by an authoritative, trusted certificate authority (CA).

RSA handshake

Look at the picture first

The specific process is as follows:

1. The browser sends client_random, TLS version, and a list of encryption suites for filtering to the server. 2. The server immediately returns server_RANDOM to verify the encryption suite and digital certificate (with Public key certificate) supported by both parties. 3. If the browser receives the certificate, verify the digital certificate. If the number passes, the RSA algorithm of the encryption suite is used to generate another random number pre_random, which is encrypted with the public key in the certificate and sent to the server. 4. The server uses the private key to decrypt the encrypted PRE_RANDOM. For details, see asymmetric Encryption.Copy the code

Both the browser and the server now have three identical credentials: client_RANDOM, server_RANDOM, and pre_RANDOM. Both mix these three random numbers using the encryption method in the sieved encryption suite to generate the final key.

Finally, the browser and server communicate using the same key, that is, symmetric encryption.

There are two other things to note here.

First: none of the messages in the handshake are encrypted with a secret key; they are all sent in clear text.

Second, the TLS handshake is a two-way authentication process. Both the client and server need to perform summary authentication and end authentication (sending a Finished message, indicating that HTTP packets begin to communicate formally).

DH handshake

Or look at the picture:

The specific process is as follows (diff comparison is released) :

1. The browser sends client_random, TLS version, and a list of encryption suites for filtering to the server.
// RSA
-2. The server immediately returns server_RANDOM to confirm the encryption suite supported by both parties
- and digital certificates (with public keys attached).
// DH +2. The server receives this message and immediately returns server_RANDOM to confirm the encryption suite supported by both parties + and digital certificates (with public keys attached). + Meanwhile, the server uses the private key to sign client_random, server_random, server_params, + Generate server signatures. The signature and server_params are then sent to the client as well. + Server_params is the parameter required by the DH algorithm.  // RSA -3. If the browser receives the certificate, verify the digital certificate. - If yes, use the RSA algorithm of the encryption suite - Generates another random number pre_random, encrypts it with the public key in the certificate, and passes it to the server. // DH +3. If the browser receives the certificate, verify the digital certificate and _ signature. + If yes, pass client_params to the server. + Client_params is the parameter required by the DH algorithm.  -4. The server uses the private key to decrypt the encrypted PRE_RANDOM. For details, see Asymmetric Encryption. +4. Now both client and server have client_params and server_params parameters. + Because ECDHE calculation is based on "discrete logarithm of elliptic curve", pre_random can be calculated by these two DH parameters. Copy the code

The browser and server now have three identical credentials: client_RANDOM, server_RANDOM, and pre_RANDOM. The next steps are consistent with the RSA handshake.

DH Handshake forward security

TLS1.2 handshake

With the concepts in the previous section, TLS1.2 handshakes are effortless to understand. The mainstream TLS1.2 handshake is the complete DH handshake procedure described in the previous section.

TLS1.3 handshake

With the rapid development of the Internet world, as time goes by, people are already not satisfied with the existing TLS1.2. The faster and safer “new version of the ship”, TLS1.3, was released.

TLS1.3 abolished some of the original insecure encryption algorithms, including RSA algorithm.

RSA was abolished not only because of the ability to crack it, but also because of the lack of forward security. What is forward security? The ability to protect past communications from future exposure of passwords or keys.

Now let’s look at the TLS1.3 handshake process, first put the figure:

Process combing:

// The original DH handshake-1. The browser sends client_RANDOM, TLS version, and the list of encryption suites for filtering to the server.
/ / TLS1.3 optimization+1. The browser sends client_params, client_RANDOM, TLS versions and a list of encryption suites to filter to the server.

// The original DH handshake- 2... / / TLS1.3 optimization+2. The server returns: server_random, server_Params, TLS version, determined cryptosuite method, and certificate. + The browser receives, and verifies the digital certificate and signature. + Now that both parties have client_params and server_params, pre_RANDOM can be calculated based on ECDHE. Copy the code

Finally, three parameters are collected to generate the final secret key.

As you can see, TLS1.3 requires only one round trip between client and server (TLS1.2 requires two round trips to complete the handshake), the 1-RTT handshake. Of course, with PSK we can even optimize to 0-RTT (which is not good, security is questionable ~).

summary

Above, we have combed through three versions of TLS handshake processes, which actually fall into two categories: one based on RSA and the other based on Diffie-Hellman (ECDHE). The two types of handshake differ only in how key establishment and authentication are implemented:

The secret key exchange The authentication
RSA handshake RSA RSA
DH handshake ECDHE RSA/DSA

As we have seen in version evolution, the latest TLS1.3 abandoned RSA for security and reduced RTT for speed. It is known that the characteristics of Internet technology innovation are nothing more than this.

extension

As mentioned earlier, the handshake is a two-way authentication process, but it is not absolute.

In the third step of the handshake, when the client authenticates the certificate, if the certificate of the server is in the default trust certificate list, the certificate will be passed directly. If it is not in the default trust certificate list, the browser may pop up and ask the user to choose whether to trust the certificate, or directly close the connection, indicating that the certificate is not trusted.

In the App, if you want to trust the certificate that is not in the system trust list, you need to place the server certificate in the App in advance. In addition, most authentication methods are one-way authentication, that is to say, only authenticate the certificate of the server, while institutions such as banks mostly use two-way authentication.

Of course, there are many more details of the handshake that I won’t go into here for space reasons, but let’s go back to one of the core aspects of the protocol: the encryption algorithm.

In the era of big data, a large amount of personal information needs to be collected for statistics.

On the one hand it brings us convenience, bundled with wealth, such as blockchain, which uses hash algorithms.

On the other hand, some personal information data in inadvertently leaked adverse consequences, such as one of the public opinion to suicide accident, the defendant’s personal data in the network, combined with the blind guide of the masses, eventually leading to the defendant and mental stress in tragedy, and the cause is an event could have negotiated solution easily.

The examples are endless, and the consequences of data breaches are incalculable.

To protect customers’ private data, ciphertext transmission is recommended regardless of HTTP or HTTPS. Of course, the performance cost of data encryption and decryption also needs to be measured by each developer.

“

The more we understand the Internet, the more we are in awe of it.

“

The last

Article output is not easy, but also hope you support a wave of friends! If there is any mistake, please correct it.

Previous selections:

“Intermediate advanced front-end interview” handwritten code collection

#fragment This article anchor jump test

The resources

wiki/HTTPS

HTTP Soul Ask – God triad

HTTPS authoritative Guide

Keyless SSL: The Nitty Gritty Technical Details

The First Few Milliseconds of an TLS 1.2 Connection

TLS 1.3 Handshake: Taking a Closer Look

Intuitively experience TLS handshake process

RFC5246

This article is formatted using MDNICE