The communication security of the Internet is based on the SSL/TLS protocol.
This article briefly introduces the operating mechanism of the SSL/TLS protocol. The focus of the article is on the design idea and operation process, and does not involve specific implementation details. If you want to learn about this, please refer to the RFC document .
1. Function
HTTP communication that does not use SSL/TLS is unencrypted communication. The dissemination of all information in plain text brings three major risks.
(1) Eavesdropping risk (eavesdropping): Third parties can learn the content of communications.
(2) Tampering risk (tampering): Third parties can modify the content of the communication.
(3) Pretending: A third party can pretend to be another person to participate in the communication.
The SSL/TLS protocol is designed to address these three major risks and hopes to achieve:
(1) All information is encrypted and transmitted, and third parties cannot eavesdrop.
(2) It has a verification mechanism. Once it is tampered with, both parties in the communication will find it immediately.
(3) Equipped with identity certificate to prevent identity from being impersonated.
The Internet is an open environment, and both sides of the communication are unknown, which brings great difficulty to the design of the protocol. Moreover, the protocol must be able to withstand all the unthinkable attacks, which makes the SSL/TLS protocol extremely complex.
2. History
The history of encrypted communication protocols on the Internet is almost as long as the Internet.
In 1994, NetScape designed version 1.0 of the SSL protocol (Secure Sockets Layer), but it was not released.
In 1995, NetScape released SSL version 2.0, which soon found serious vulnerabilities.
In 1996, SSL version 3.0 came out and was widely used.
In 1999, the Internet Standardization Organization ISOC succeeded NetScape and released an upgraded version of SSL, TLS 1.0.
In 2006 and 2008, TLS underwent two upgrades, TLS version 1.1 and TLS version 1.2. The latest change is the 2011 revision of TLS 1.2 .
Currently, the most widely used is TLS 1.0, followed by SSL 3.0. However, major browsers have implemented TLS 1.2 support.
TLS 1.0 is usually designated 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 SSL/TLS protocol is to use public key encryption method , that is to say, the client first asks the server for the public key, and then encrypts the information with the public key. After the server receives the ciphertext, it decrypts it with its own private key.
However, there are two problems here.
(1) How to ensure that the public key is not tampered with?
Workaround: Put the public key in the digital certificate . As long as the certificate is trusted, the public key is trusted.
(2) The amount of calculation of public key encryption is too large, how to reduce the time consumed?
Solution: For each session, the client and server generate a "session key", which is used to encrypt information. Since the "session key" is symmetric encryption, the operation speed is very fast, and the server public key is only used to encrypt the "session key" itself, which reduces the consumption time of encryption operation.
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 use the "conversation key" for encrypted communication.
The first two steps of the above process are also called "handshake".
Fourth, the detailed process of the handshake stage
The "handshake phase" involves four communications, let's look at them one by one. It is important to note that all communications in the "handshake phase" are in clear text.
4.1 The client sends a request (ClientHello)
First, the client (usually the browser) makes a request for encrypted communication to the server, which is called a ClientHello request.
In this step, the client mainly provides the following information to the server.
(1) The supported protocol version, such as TLS version 1.0.
(2) A client-generated random number that is later used to generate a "session key".
(3) Supported encryption methods, such as RSA public key encryption.
(4) Supported compression methods.
It should be noted here that the information sent by the client does not include the domain name of the server. That is to say, in theory, the server can only contain one website, otherwise it will be unclear which website's digital certificate should be provided to the client. This is why usually a server can only have one digital certificate.
This is of course inconvenient for users of web hosting. In 2006, a Server Name Indication extension was added to the TLS protocol , allowing the client to provide the server with the domain name it requested.
4.2 Server response (SeverHello)
After the server receives the client request, it sends a response to the client, which is called SeverHello. The server's response contains the following.
(1) Confirm the encrypted communication protocol version used, such as TLS 1.0 version. 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 a "session 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 confirm the identity of the client, it will include a request for the client to provide a "client certificate". For example, financial institutions often only allow authenticated clients to connect to their own networks, and will provide formal clients with USB keys that contain a client certificate.
4.3 Client response
After the client receives the response from the server, it first verifies 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, who can choose whether to continue the communication.
If there is no problem with the certificate, the client will extract 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) Code change notification, indicating that subsequent information will be sent using the encryption method and key agreed upon by both parties.
(3) The client's handshake end notification indicates that the client's handshake phase has ended. This item is also the hash value of all the content sent before, which is used for server verification.
The random number of the first item above is the third random number that appears in the entire handshake phase, also known as "pre-master key". With it, the client and the server have three random numbers at the same time, and then the two parties use the pre-agreed encryption method to generate the same "session key" used in this session.
As for why it is necessary to use three random numbers to generate the "session key", dog250 explained it very well:
"Whether it is a client or a server, a random number is required, so that the generated key will not be the same every time. Since the certificate in the SSL protocol is static, it is very necessary to introduce a random factor to ensure the negotiated password. The randomness of the key.
For the RSA key exchange algorithm, the pre-master-key itself is a random number, plus the random number in the hello message, three random numbers through a key exporter finally derive a symmetric key.
The existence of the pre master lies in the fact that the SSL protocol does not trust that each host can generate a completely random random number. If the random number is not random, then the pre master secret may be guessed, so it is not suitable to use the pre master secret as the key only. Therefore, a new random factor must be introduced, then the key generated by the client and the server plus the three random numbers of the pre master secret cannot be easily guessed. A pseudo-random may not be random at all, but three Pseudo-random is very close to randomness. For every degree of freedom added, the randomness does not increase by one. "
Also, if the server requested a client certificate in the previous step, the client will send the certificate and related information in this step.
4.4 The last response from the server
After the server receives the third random number pre-master key from the client, it calculates and generates the "session key" used for this session. Then, the following information is finally sent to the client.
(1) Code change notification, indicating that subsequent information will be sent using the encryption method and key agreed upon by both parties.
(2) The server handshake end notification, indicating that the server's handshake phase has ended. This item is also the hash value of all the content sent previously, which is used for client verification.
At this point, the entire handshake phase is over. Next, the client and the server enter encrypted communication, which is completely using the ordinary HTTP protocol, but encrypts the content with the "session key".
5. Reference links
- MicroSoft TechNet, SSL/TLS in Detail
- Jeff Moser, The First Few Milliseconds of an HTTPS Connection
- Wikipedia, Transport Layer Security