Overview of the SSL/TLS Protocol Operating Mechanism

The communication security of the Internet is built on the SSL/TLS protocol.

This article briefly introduces the operation mechanism of the SSL/TLS protocol. The focus of this article is on the design idea and operation process, with no specific implementation details involved. For more information, see the RFC documentation.

I. Role

HTTP Communication without SSL/TLS is not encrypted. Plaintext transmission of all information poses three major risks.

(1) eavesdropping risk (eavesdropping): a third party can obtain the communication content.

(2) Risk of tampering (tampering): a third party can modify the communication content.

(3) pretending: A third party can impersonate another person to participate in communication.

The SSL/TLS protocol is designed to address these three risks:

(1) All information is encrypted and cannot be eavesdropped by a third party.

(2) There is a verification mechanism. Once tampered with, both parties will immediately discover the communication.

(3) equipped with an ID card to prevent identity impersonation.

The Internet is an open environment, and both parties are UNKNOWN identities, which makes the design of the Protocol very difficult. Moreover, the Protocol must be able to withstand all the incredible attacks, which makes the SSL/TLS Protocol extremely complex.

Ii. History

The history of Internet encrypted communication protocols is almost as long as that of the Internet.

In 1994, Netscape designed the SSL protocol (Secure Sockets Layer) Version 1.0, but it was not released.

On July 15, 1995, Netscape released SSL 2.0 and soon found a serious vulnerability.

In 1996, SSL 3.0 was launched and widely used.

On June 18, 1999, Internet Standardization Organization ISOC took over Netscape and released the upgraded version of TLS 1.0 for SSL.

In 2006 and 2008, TLS was upgraded twice, including TLS 1.1 and TLS 1.2. The latest change is the revision of TLS 2011 in 1.2.

Currently, TLS 1.0 is the most widely used, followed by SSL 3.0. However, mainstream browsers have achieved TLS 1.2 Support.

TLS 1.0 is usually labeled as SSL 3.1, TLS 1.1 is SSL 3.2, and TLS 1.2 is SSL 3.3.

3. Basic operation process

The basic idea of the SSL/TLS protocol is to adopt the public key encryption method. That is to say, the client requests the public key from the server and then encrypts the information with the public key. After the server receives the ciphertext, use your own private key for decryption.

However, there are two problems.

(1) how to ensure that the public key is not tampered?

Solution: place the public key in the digital certificate. As long as the certificate is trusted, the Public Key is trusted.

(2) public key encryption requires a large amount of computing. How can we reduce the time consumed?

Solution: For each session, both the client and the server generate a session key to encrypt the information. Because the "conversation key" is symmetric encryption, the calculation speed is very fast, and the server Public Key is only used to encrypt the "conversation key" itself, which reduces the time consumption of encryption operations.

Therefore, the basic process of the SSL/TLS Protocol is as follows:

(1) The client requests and verifies the public key from the server.

(2) Both parties negotiate to generate a "conversation key ".

(3) Both Parties adopt the "conversation key" for encrypted communication.

The first two steps of the above process are also called handshake ).

4. Detailed handshake process

The handshake phase involves four communications. Let's look at them one by one. Note that all communications in the handshake phase are in plain text.

4.1 client sends a request (ClientHello)

First, the client (usually a browser) sends an encrypted communication request to the server, which is called a ClientHello request.

In this step, the client mainly provides the following information to the server.

(1) Supported Protocol versions, such as TLS 1.0.

(2) a random number generated by a client, which is used to generate a "conversation key" later ".

(3) supported encryption methods, such as RSA public key encryption.

(4) supported compression methods.

Note that the information sent by the client does not include the Domain Name of the server. That is to say, theoretically, the server can only contain one website, otherwise it will not be clear which website's digital certificate should be provided to the client. This is why one server can only have one digital certificate.

This is of course inconvenient for VM users. In 2006, the TLS Protocol added a server name indication extension that allows the client to provide the server with the domain name it requested.

4.2 Server Response (severhello)

After receiving a request from the client, the server sends a response to the client, which is called severhello. The server response includes the following content.

(1) confirm the encrypted communication protocol version used, such as TLS 1.0. If the browser is different from the version supported by the server, the server disables encrypted communication.

(2) a random number generated by a server, which is used to generate a "conversation key" later ".

(3) confirm the encryption method used, such as RSA public key encryption.

(4) server certificate.

In addition to the above information, if the server needs to confirm the identity of the client, it will contain another request, requiring the client to provide a "client certificate ". For example, financial institutions often only allow authenticated customers to connect to their own networks, and then provide formal customers with a USB key, which contains a client certificate.

4.3 client response

After receiving the server response, the client first verifies the server certificate. If the certificate is not issued by a trusted organization, the domain name in the certificate is inconsistent with the actual domain name, or the certificate has expired, a warning will be displayed to the visitor, and the visitor will choose whether to continue communication.

If the certificate is correct, the client extracts the server's public key from the certificate. Then, send the following three messages to the server.

(1) a random number. The random number is encrypted with the server public key to prevent eavesdropping.

(2) The code change notification indicates that subsequent information will be sent using the encryption method and key agreed by both parties.

(3) Client handshake end notification, indicating that the client handshake stage has ended. This item is also the hash value of all previously sent content for server verification.

The random number of the first item above is the third random number in the entire handshake phase, also known as "pre-master key ". With this, the client and server have three random numbers at the same time. Then, the two parties use the pre-agreed encryption method to generate the same "session key" for this session ".

Dog250 explains why three random numbers must be used to generate a "session key:

"A random number is required for both the client and server, so that the generated key will not be the same every time. Because the certificate in the SSL protocol is static, it is necessary to introduce a random factor to ensure the randomness of the negotiated key.

For the RSA key exchange algorithm, the pre-master-Key itself is a random number. In addition to the random number in the Hello message, the three random numbers are exported to a symmetric key through a key export tool.

The existence of pre master lies in the fact that the SSL protocol does not trust each host to generate a random number completely. If the random number is not random, the PRE master secret may be guessed, therefore, it is not appropriate to use only the pre master secret as the key. Therefore, a new random factor must be introduced, the key generated by the client and the server together with the PRE master secret three random numbers is not easy to guess. A pseudo random may not be random at all, however, three pseudo-random values are very close to random values. Each increase in degrees of freedom is not a random increase. "

In addition, if the server requires a client certificate in the previous step, the client will send the certificate and related information in this step.

4.4 server final response

After receiving the third random number pre-master key from the client, the server calculates the "session key" used to generate the session ". Then, send the following information to the client.

(1) The code change notification indicates that subsequent information will be sent using the encryption method and key agreed by both parties.

(2) indicates that the handshake has ended. This item is also the hash value of all previously sent content for client verification.

At this point, the entire handshake phase is complete. Next, when the client and the server enter encrypted communication, the common HTTP protocol is used, but the "session key" is used to encrypt the content.

V. Reference Links

• Microsoft technet, SSL/TLS in detail
• Jeff Moser, the first few milliseconds of an HTTPS connection
• Wikipedia, Transport Layer Security
• Stackexchange, how does SSL work?

Reproduced http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

Overview of the SSL/TLS Protocol Operating Mechanism