Internet communication security is based on SSL/TLS protocol.
This article briefly introduces the operation mechanism of SSL/TLS. This paper focuses on the design idea and operation process, not specific implementation details. See the RFC documentation if you want to learn more about this. A,
HTTP communication without SSL/TLS is unencrypted communication. With all information in plain text, there are three main risks.
(1) Eavesdropping: The contents of communications may be known to a third party.
(2) Tampering risks: Third parties may modify communications.
(3) Impersonation risk (pretending) : a third party may impersonate the identity of others to participate in communication.
The SSL/TLS protocol is designed to address these three risks, hoping to achieve:
(1) All information is encrypted and cannot be wiretapped by a third party.
(2) With verification mechanism, once tampered, communication parties will immediately discover.
(3) Equipped with identity certificate to prevent identity from being impersonated.
The Internet is an open environment, and the communication parties are unknown, which brings great difficulty to the design of the protocol. Also, the protocol must be able to withstand all sorts of mind-boggling attacks, which makes SSL/TLS extremely complex.
Second, the history
The history of encrypted communication protocols on the Internet is almost as old as the Internet itself.
In 1994, NetScape designed version 1.0 of the Secure Sockets Layer protocol, but did not release it.
In 1995, NetScape released VERSION 2.0 of SSL and soon discovered serious bugs.
In 1996, SSL 3.0 came out and was widely used.
In 1999, the Internet Standardization Organization ISOC took over from NetScape and released TLS 1.0, an updated version of SSL.
In 2006 and 2008, TLS was upgraded to TLS 1.1 and TLS 1.2 respectively. The latest change is a revision of TLS 1.2 from 2011.
Currently, TLS 1.0 is the most widely used, followed by SSL 3.0. However, TLS 1.2 is already supported by major browsers.
TLS 1.0 is usually labeled AS SSL 3.1, TLS 1.1 as SSL 3.2, and TLS 1.2 as SSL 3.3.
Three, the basic operation process
The BASIC idea of THE SSL/TLS protocol is to use the public key encryption method. That is, the client first requests the public key from the server, and then encrypts the information using the public key. After receiving the ciphertext, the server uses its private key to decrypt it.
But there are two problems.
(1) How to ensure that the public key is not tampered with?
Solution: Put the public key in the digital certificate. The public key is trusted as long as the certificate is trusted.
(2) Public key encryption calculation is too large, how to reduce the consumption of time?
Solution: For each session, the client and server generate a session key, which is used to encrypt information. Because the “conversation key” is symmetrically encrypted, the operation is very fast, whereas the server public key is only used to encrypt the “conversation key” itself, which reduces the time consumed in the encryption operation.
Thus, the basic process of the SSL/TLS protocol looks like this:
(1) The client requests and verifies the public key from the server.
(2) Both parties negotiate to generate the “dialogue key”.
(3) Both parties use the “dialogue key” for encrypted communication.
The first two steps are called the handshake.
4. Detailed process of handshake stage
The handshake phase involves four communications, so let’s look at each one. Note that all communication in the “handshake phase” is in clear text.
4.1 Sending a Request from a Client (ClientHello)
First, the client (usually a browser) makes a request to the server to encrypt the communication. This is called a ClientHello request.
In this step, the client mainly provides the following information to the server.
(1) Supported protocol version, such as TLS version 1.0.
(2) a client-generated random number that is later used to generate the “conversation key”.
(3) Supported encryption methods, such as RSA public key encryption.
(4) Supported compression methods.
Note that the server’s domain name is not included in the message sent by the client. That is, the server can theoretically contain only one web site, otherwise it would be confusing which web site’s digital certificate should be provided to the client. This is why there is usually only one digital certificate per server.
For virtual host users, this is of course very inconvenient. In 2006, the TLS protocol added a Server Name Indication extension that allows a client to provide a requested domain Name to the Server.
4.2 Server Response (SeverHello)
When the server receives a client request, it sends a response to the client. This is called SeverHello. The server’s response contains the following.
(1) Confirm the version of the encrypted communication protocol, such as TLS 1.0. If the browser does not match the version supported by the server, the server turns off encrypted communication.
(2) A server-generated random number that is later used to generate the “conversation key”.
(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 verify the identity of the client, it will include a request for a “client certificate.” For example, financial institutions tend to allow only authenticated customers to connect to their networks, and will provide a USB key containing a client certificate to a regular customer.
4.3 Client Response
After receiving a response from the server, the client first validates the server certificate. If the certificate is not issued by a trusted authority, or the domain name in the certificate is inconsistent with the actual domain name, or the certificate has expired, a warning is displayed to the visitor and he or she can choose whether to continue the communication.
If there is nothing wrong with the certificate, the client retrieves the server’s public key from the certificate. Then, send the following three pieces of information to the server.
(1) a random number The random number is encrypted with the server’s public key to prevent eavesdropping.
(2) Notification of encoding change, indicating that subsequent information will be sent using encryption methods and keys agreed by both parties.
(3) Notification of the end of client handshake, indicating the end of client handshake. This item is also the hash value of all the previously sent content for the server to verify.
The first random number is the third random number in the handshake phase, also known as the “pre-master key”. With this, the client and server have three random numbers at the same time, and each generates the same “session key” for the session using a pre-agreed encryption method.
Dog250 explains why it is necessary to use three random numbers to generate “session keys” :
“Both the client and the server need random numbers so that the generated key is not the same every time. Because SSL certificates are static, it is necessary to introduce a randomness factor to ensure the randomness of the negotiated keys.
For the RSA key exchange algorithm, the pre-master-key itself is a random number, plus the randomization in the Hello message, three random numbers through a key exporter finally exported a symmetric key.
The existence of Pre Master is that SSL protocol does not trust each host to generate a completely random random number. If the random number is not random, pre Master Secret may be guessed, so it is not appropriate to only apply Pre Master Secret as the key. Therefore, it is necessary to introduce a new random factor, so it is not easy to guess the key generated by the client and server together with pre Master secret. One pseudo-random may not be random at all, but three pseudo-random will be very close to random. Every increase of one degree of freedom, the randomness will not increase by one.”
In addition, if the server requested a client certificate in the previous step, the client sends the certificate and related information in this step.
4.4 Final Response from the server
After receiving the third random pre-master key from the client, the server calculates and generates the session key used for the session. Then, the following information is finally sent to the client.
(1) Notification of encoding change, indicating that subsequent information will be sent using the encryption method and key agreed by both parties.
(2) Notification indicating that the handshake phase of the server is over. This item is also the hash value of all the previously sent content for the client to verify.
At this point, the whole handshake phase is over. Next, the client and server enter encrypted communication using the plain HTTP protocol, but with a “session key” to encrypt the content.
