This paper mainly wants to explain the following issues:
1. What problem does HTTPS solve?
2. How does HTTPS solve the security problem of data transmission over the network?
3. How does HTTPS work?
4. How do I use HTTPS?
I. What problem does HTTPS solve
HTTP is transmitted in plaintext. The following risks (hereinafter referred to as Risk 1, Risk 2, and Risk 3) occur during the transmission:
- Content eavesdropping: Data is seen by a third party during transmission
- Content tampered: Data is modified by a third party during transmission
- Impersonated by a third party: During communication, the identity of the third party is assumed to communicate with the bank. For example, the identity of the third party is assumed to communicate with the bank and transfer money.
HTTPS is designed to solve these three problems.
How does HTTPS solve the security problem of data transmission in the network
To solve the problem of eavesdropping, the simplest solution is encryption. The client sends the request to the server, and the server returns the encrypted data to the client. The client decrypts the data using the key to obtain the content. In this process, only the client and the server that communicates with it have the key. Therefore, if the security of the encryption algorithm is strong enough, the data can be prevented from being seen by the third party. And because the encryption method is unknown, the content of the communication cannot be tampered with and is less likely to be impersonated.
Of course, this is only the ideal situation. In the Internet environment, each server and client use a different key to communicate and use different keys during different sessions. Before communicating, the two parties must agree on which key to use or which key to store, which is almost impossible in practice.
In order to solve the problem of key distribution, HTTPS adopts asymmetric encryption algorithm. Since there is asymmetric encryption, there must be symmetric encryption. Here is the difference.
** Symmetric encryption: ** As shown below, encryption and decryption use the same key, and decryption is the reverse of encryption.
** Asymmetric encryption: ** Corresponding to symmetric encryption, asymmetric encryption has two keys, a public key and a private key. The public key and private key are a pair and can only be used together. Although the two are related, the private key cannot be inferred from the public key and vice versa. You can encrypt with the public key and decrypt with the private key, or you can encrypt with the private key and decrypt with the public key. Asymmetric encryption has strong confidentiality and high security, but due to the complexity of the algorithm, the operation speed is relatively slow.
With asymmetric encryption, the problem of key distribution seems to be solved. Suppose A and B each have their own public and private keys. Then the communication process between A and B can be:
(1) A and B exchange their public keys.
(2) A uses THE public key of B, encrypts the request, and sends it to B.
(3) B obtains the request content using the private key, encrypts the response data using the public key of A, and sends it to A
(4) A decrypts data with its own private key to obtain plaintext.
Let’s analyze the above process. First of all, this process can prevent risk 1. For risk 2, even if it is tampered with and cannot be correctly decrypted by A, its damage is limited. 3 for risk, if the middleman C can obtain A, B content of communication, it can be in step (1) A, B’s public key, and then give their public key distribution respectively to A, B, A, B in the process of sending information is the public key encryption in C, C can use your own private key to decrypt, and A and B.
The reason for this problem is that the communication parties cannot know the authenticity of the public key obtained from the other party. To solve the problem of public key authenticity, HTTPS uses digital certificates to ensure the authenticity of public keys.
Digital Certificate:
The server will apply to the authority for a digital certificate.
The digital certificate contains the public key used to encrypt the browser, basic information about the applicant, but is encrypted using the organization’s private key.
During the communication, the browser obtains the certificate returned by the server. Firstly, the browser is installed with the certificate of the trusted authority. If the two parties are trusted, the public key of the private key used by the trusted authority to encrypt the plaintext is stored in the browser. The browser uses the public key to decrypt the basic information of the server. If the information is the same as the server information requested by the browser, the information is correct and the browser can obtain the public key of the server. In this process, if a third party wants to pretend to be the server and communicate with the browser, it cannot do so because there is no trusted certificate, or even if there is a trusted certificate, the identity information in the integer cannot be modified and will not be accepted by the browser in the authentication process.
However, there is a problem with asymmetric encryption algorithm: due to the complexity of the algorithm, the operation time is long. If the public key is used to encrypt data in every communication, it will be time-consuming. As we said above, if the problem of key distribution between communication parties can be solved, the use of symmetric encryption with short computing time is also sufficient for security. Therefore, HTTPS adopts the symmetric encryption and asymmetric encryption policy. The asymmetric encryption algorithm is only used to exchange the symmetric encryption key and encryption algorithm. The symmetric encryption algorithm is used to encrypt data in subsequent communication, which is both secure and efficient.
Iii. Running process of HTTPS
(1) The client requests and verifies the public key from the server.
(2) Both parties negotiate to generate a “conversation key “(symmetric encryption algorithm key).
(3) Both parties shall use the “dialogue key” for encrypted communication.
The first two steps are the handshake phase. Details are as follows:
1. The browser sends a request for encrypted communication to the server. The request is as follows:
(1) Supported protocol versions, such as TLS 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.
2. After receiving the request, the server responds to the browser. The contents are as follows:
(1) Confirm the encrypted communication protocol version used, such as TLS 1.0. If the version supported by the browser is different from that supported by the server, the server disables encrypted communication.
(2) A random number generated by the server that is later used to generate the “conversation key”.
(3) Confirm the encryption method used, such as RSA public key encryption.
(4) Server certificate.
3. After receiving the response from the server, the browser checks whether the certificate is issued by a trusted authority and whether it has expired. If the certificate is normal, the browser uses the private key in the built-in certificate to decrypt the certificate returned by the server and obtain information such as the server domain name. If it is the same as the server domain name, the verification succeeds. Take out the public key in the server certificate. Send a concurrent message to the server as follows:
(1) A random number. The random number is encrypted with the server public key to prevent eavesdropping.
(2) Code change notification, indicating that subsequent messages will be sent using an agreed encryption method and key.
(3) Browser handshake end notification, indicating that the browser handshake phase has ended. This item is also the hash value of all the previously sent content for the server to verify.
4. After receiving the message, the server generates a key based on the three random numbers of the previous three communications and the agreed encryption algorithm. Then send the following message to the browser:
(1) Code change notification, indicating that subsequent messages will be sent using an agreed encryption method and key.
(2) Server handshake end notification, indicating that the server handshake phase has ended. This item is also the hash value of all the previously sent content for client verification.
Three random numbers are used to increase the randomness, increase the randomness of the algorithm, because computer-generated random numbers are generally pseudorandom numbers, using three pseudorandom numbers, can be approximated as random numbers.
After the above four steps, the browser and the server agree on the key for the communication, and there is no difference between each communication and THE HTTP communication, except that the information is encrypted with the key.
The HTTPS session is often interrupted due to certain reasons. If it takes time to restart the handshake, you can use the session ID or session ticket to restore the HTTPS session.
How to Use HTTPS
1. Obtain the certificate
2. Install the certificate on the server
3. Change the HTTP resources loaded on the web page to HTTPS links. Because if there are unencrypted resources on an encrypted page, the browser will not load those resources.
4. Modify the server configuration to redirect HTTP to HTTPS
References:
1.zhuanlan.zhihu.com/p/43789231
2.zhuanlan.zhihu.com/p/36981565
3. www.ruanyifeng.com/blog/2014/0…
4. www.ruanyifeng.com/blog/2016/0…