1. Why use https
The reason for using https is actually very simple, because http is insecure.
When we send more private data (such as your bank card, ID card) to the server, if you use http for communication. Then security will not be guaranteed. First of all, in the process of data transmission, the data may be captured by the middleman, and the data will be stolen by the middleman. Secondly, after the data is obtained by the middleman, the middleman may modify or replace the data and then send it to the server. Finally, after the server receives the data, it cannot determine whether the data has been modified or replaced. Of course, if the server cannot determine that the data really comes from the client.
In summary, http has three drawbacks:
- The confidentiality of the message cannot be guaranteed
- The completeness and accuracy of the message cannot be guaranteed
- The reliability of the source of the information cannot be guaranteed
https was born to solve the above problems.
Second, the basic concepts involved in https
In order to solve the problems existing in http, https adopts some encryption and decryption, digital certificates, and digital signature technologies. Let’s first introduce the basic concepts of these technologies.
1. Symmetric encryption and asymmetric encryption
In order to ensure the confidentiality of the message, encryption and decryption are needed. The current mainstream encryption and decryption algorithms are divided into symmetric encryption and asymmetric encryption.
1. Symmetric encryption (shared key encryption): The client and server share a key to encrypt and decrypt messages. This method is called symmetric encryption. The client and server agree on an encryption key. The client uses the key to encrypt the message before sending the message, and after sending it to the server, the server uses the key to decrypt the message to get the message.
The advantages of symmetric encryption: symmetric encryption solves the problem of message confidentiality in http
Disadvantages of symmetric encryption: 1. Although symmetric encryption guarantees the confidentiality of messages, the client and server share a key, which makes the key particularly easy to leak.
2. Because the risk of key leakage is high, it is difficult to guarantee the reliability of the source of the message, and the integrity and accuracy of the message.
2. Asymmetric encryption (public key encryption): Since the key is so easy to leak in symmetric encryption, we can use an asymmetric encryption method to solve it. When using asymmetric encryption, both the client and the server have a public key and a private key. The public key can be exposed to the outside, while the private key is only visible to you. Messages encrypted with the public key can only be unlocked by the corresponding private key. Conversely, messages encrypted with the private key can only be unlocked by the public key. In this way, the client first encrypts the message with the server's public key before sending it, and then decrypts it with its own private key after the server receives it.
The advantages of asymmetric encryption: 1. Asymmetric encryption uses public and private keys, which solves the problem of message confidentiality in http and reduces the risk of private key leakage.
2. Because the public key encrypted message can only be unlocked by the corresponding private key, the source of the message and the accuracy and completeness of the message are ensured to a greater extent.
Disadvantages of asymmetric encryption: 1. In asymmetric encryption, the recipient's public key is needed to encrypt the message, but the public key is not confidential, anyone can get it, and the middleman can also. Then the middleman can do two things. The first thing is that the middleman can replace the client's public key with his own when the client exchanges the public key with the server. In this way, the public key obtained by the server will not belong to the client but the server. The server cannot determine the correctness of the source of the public key. The second thing is that the middleman can not replace the public key, but he can intercept the message sent by the client, tamper with it, and then encrypt it with the server's public key and send it to the server. The server will receive the wrong message.
2. The performance of asymmetric encryption is several times or even hundreds of times slower than that of symmetric encryption, which consumes system resources. It is precisely because of this that https combines two encryptions.
2. Digital certificate and digital signature
In order to solve the insecurity of the source of the public key in asymmetric encryption. We can use digital certificates and digital signatures to solve this problem.
1. Application for digital certificate
In reality, there are some specialized authorities used to issue digital certificates. We call these organizations the CA Certificate Authority. We (the server) can apply for digital certificates from these CAs. The application process is roughly as follows: first generate a pair of keys locally, and then take your own public key and other information (such as the name of the company) to the CA to apply for a digital certificate. After the CA obtains the information, it will choose a one-way Hash algorithm (such as the common MD5) to encrypt the information, and the encrypted thing is called the digest. One characteristic of the one-way Hash algorithm is that it is one-way irreversible. As long as the original content changes a little, the encrypted data will be very different (of course, there is a small possibility that it will be repeated. If you are interested, learn about the pigeon nest principle. ), which prevents the information from being tampered with. After the digest is generated, the CA will also encrypt the digest with its own private key. The data after the digest is encrypted is called a digital signature. Finally, the CA will integrate our application information (including the server's public key) with the digital signature to generate a digital certificate. Then the CA passes the digital certificate to us (this may lead to another question, how can the certificate authority safely pass the digital certificate to the server? What if the digital certificate is replaced by an intermediary during the transmission process? For this question In fact, if we apply now, the certification center is passed to us via https. But when there is no https at the beginning? Actually, I don’t really understand, but there is no need to entangle it, because it’s like a chicken. Laying eggs, never ending, we think that digital certificates are not something anyone can apply for, and strict certification is required. Anyway, digital certificates can safely reach the server).
2. How does a digital certificate work?
After the server obtains the digital certificate, the server sends the digital certificate to the client, and the client needs to use the CA's public key to decrypt the digital certificate and verify the legitimacy of the digital certificate. How can we get the CA's public key? Some of the root certificates of the authority have been built into our computers and browsers, and these root certificates contain the public key of the CA.
The reason for the root certificate is that in real life, the certification centers are hierarchical, that is to say, there are top certification centers, as well as the certification centers of each sub-level below. It is a tree structure, and the built-in computer is the most The root certificate of the top-level organization, but don’t worry, the public key of the root certificate is also applicable to the sub-level.
The client uses the CA's public key to decrypt the digital certificate. If the decryption is successful, the certificate comes from a legal certification authority. After the decryption is successful, the client gets the digest. At this time, the client will generate a summary of the application information according to the same Hash algorithm as the CA, and compare it with the decrypted copy. If the same, the content is complete and has not been tampered with. Finally, the client securely obtains the server's public key from the certificate and can communicate with the server in secure asymmetric encryption. The server wants to obtain the client's public key in the same way.
The following figure illustrates the general certificate application and use process in a graphical way.
Three, https principle
Through the above study, we understand the characteristics, advantages and disadvantages of symmetric encryption and asymmetric encryption, as well as the role of digital certificates. https does not use a single technology to achieve, but according to their characteristics, fully integrate these technologies to achieve maximum performance and safety. This integrated technology is called SSL (Secure Scoket Layer). So https is not a new protocol, it just puts an encrypted shell on http.
The establishment of https
Let's take a look at the established flowchart:
Here, https establishment to disconnection is divided into 6 stages and 12 processes. The following will explain the 12 processes one by one
1. The client starts SSL communication by sending a Client Hello message. The message contains the specified version of SSL supported by the client and the list of encryption components (Cipher Suite) (the encryption algorithm used and the key length, etc.).
2. When the server can perform SSL communication, it will respond with a Server Hello message. Like the client, the SSL version and encryption components are included in the message. The content of the encryption component of the server is filtered from the received encryption component of the client.
3. The server sends a certificate message. The message contains the public key certificate.
4. Finally, the server sends a Server Hello Done message to notify the client that the initial SSL handshake negotiation part ends.
5. After the first SSL handshake ends, the client responds with a Client Key Exchange message. The message contains a random password string called Pre-master secret used in communication encryption. The message has been encrypted with the public key in step 3.
6. Then the client continues to send Change Cipher Spec messages. The message will prompt the server that the communication after this message will be encrypted with the Pre-master secret key.
7. The client sends a Finished message. This message contains the overall check value of all messages connected so far. Whether the handshake negotiation can be successful is determined by whether the server can correctly decrypt the message.
8. The server also sends a Change Cipher Spec message
9. The server also sends a Finished message
10. After the Finished message of the server and the client are exchanged, the SSL connection is established. Of course, the communication will be protected by SSL. From here, the communication of the application layer protocol is started, that is, an HTTP request is sent.
11. Application layer protocol communication, that is, send HTTP response.
12. Finally, the client is disconnected. When the connection is disconnected, a close_notify message is sent. The above figure has made some omissions. After this step, send a TCP FIN message to close the communication with TCP.
In addition, in the above flowchart, a message digest called MAC (Message Authentication Code) is attached when the application layer sends data. MAC can find out whether the message has been tampered with, so as to ensure the integrity of the message.
Let's use a diagram to illustrate it visually. This diagram is more detailed than the diagram of the digital certificate above (the picture is from "Illustrated HTTP")
After the above introduction, we can see that https first uses a digital certificate to ensure that the public key of the server can reach the client safely and without error. Then use asymmetric encryption to safely transfer the shared key, and finally use the shared key to securely exchange data.
Fourth, the use of https
https is so secure, are we going to use https for communication in what scenarios? the answer is negative.
1. Although https provides a channel for secure message transmission, the encryption and decryption of each message is time-consuming and the message system resources. Therefore, unless in some scenarios with relatively high security, such as banking systems and shopping systems, we must use https for communication, and in other scenarios with low security requirements, we actually do not need to use https.
2. The use of https requires the use of digital certificates, but generally digital certificates issued by authoritative institutions are charged, and the price is also high, so for some personal websites, especially students, if the security requirements are not high, There is no need to use https.
Reference
https://www.jianshu.com/p/4932cb1499bf
https://mp.weixin.qq.com/s/StqqafHePlBkWAPQZg3NrA
"Illustrated HTTP"