Why does HTTP need encryption
The disadvantage of HTTP
-
Communications use clear text (not encryption) and the content can be eavesdropped
Because the Internet is composed of the network that can be connected to the whole world, when the client and server communicate, there are all kinds of network equipment, switches and so on on the communication line, so it is not excluded that a link will be malicious peeping behavior.
-
The identity of the communicating party is not verified, so it is possible to encounter camouflage
Requests and responses in HTTP do not acknowledge the communicator. That is, there are questions like “is the server really the host specified in the URI that sent the request, and is the response actually returned to the client that actually made the request?
-
The integrity of the message could not be proved, so it may have been tampered with
Completeness refers to the accuracy of information. Failure to prove its completeness usually means it is impossible to determine whether the information is accurate.
Encryption prevents eavesdropping
When we want to transmit a secret number to a person like: 123456, we can specify in advance that the number to be transmitted is the one after the increment of each digit, such as 234567. When the other party gets the number, it can decrypt it by decreasing one by one to obtain the number we want to transmit initially, which is the process of encrypted transmission. When someone in the middle gets 234567, It doesn’t know the actual content of our communication is 123456.
Symmetric encryption
Symmetric encryption means that the two parties use the same encryption algorithm to communicate with each other using the same key. The preceding example is a symmetric encryption. However, there is a security problem in this way. How to make the communication parties obtain the same key? If the server directly transmits the key to the client, the transmission process may also be intercepted.
Asymmetric encryption
Asymmetric encryption, also known as public-key encryption, is born to solve the security problems in symmetric encryption. One is called a public key, which is the public key, and the other is called a private key, which is the private key. But its encryption speed is very slow compared to symmetric encryption.
- A public key is open to the public, and a private key is owned by the public.
- Data encrypted with a public key can only be decrypted with a private key.
- Data encrypted with a private key can only be decrypted with a public key.
Note: Data encrypted by the public key cannot be decrypted by the public key. (Public key encryption private key solution, private key encryption public key solution)
The combination of symmetric and asymmetric encryption allows information to be transmitted confidentially
We can make the server transfer a public key to the client, and then the client generates a ciphertext, which is encrypted and transmitted to the server through the public key. Even if the intermediate device intercepts the public key, because the public key cannot unlock the encrypted data, the intermediate device cannot obtain the encrypted content transmitted at this time. In this way, the encrypted key is securely transmitted to the server, which then decrypts the key using the private key. The subsequent data transmission is encrypted and transmitted using the server and client’s unique key.
Integrity of information (digital signature)
In the process of information transmission, our information is likely to be hijacked and tampered by a third party, so we need to ensure the integrity of information. The general method is to use hash algorithms such as SHA1 and MD5 to transmit the content hash once to obtain the hash value, namely the digest. The client uses the public key of the server to encrypt the abstract and the information content, and then transmits the information to the server. The server uses the private key to decrypt the original content and the abstract value. In this case, the server uses the same hash algorithm to hash the original content and compares it with the abstract value.
The digital certificate
If the intermediate device also generates a set of public and private keys, and passes its public key to the client when the server transmits information, the intermediate device intercepts the key transmitted by the client. That is, the client cannot tell whether the public key has been passed from the server or from an attacker in the middle. An identification mechanism is needed to verify that the public key has been passed from the server.
In order to solve this problem, we can use a third-party organization to prove the authenticity of the server. This organization is just like our university. When we graduate, the university will issue us a graduation certificate with official seal.
Public key certificates issued by the DIGITAL Certificate Authority (CA) and its related authorities can be used.
First, the server authenticates its domain name and public key from the organization to obtain a certificate. After identifying the applicant, the third-party organization uses its private key to encrypt the certificate and the public key of the server.
The server sends the public key certificate issued by the Digital Certificate Authority to the client. How do you secure the public key of a third party to a client? In other words, how does the client know that this is the public key of a third-party organization? In fact, the public keys of authoritative third-party organizations are embedded in each operating system without communication. Therefore, when receiving the server certificate, you only need to use the public keys embedded in the operating system to decrypt it. In this way, through certificate authentication, the client can identify that the public key in the certificate is actually transmitted to its own server and not to another intermediate server. Then use the public key of the server to encrypt the ciphertext generated by the user and send it to the server. This key can then be used to transmit data symmetrically.
Communication steps
- Step 1: The Client sends a Client Hello packet to start SSL communication. The packet contains the specified VERSION of SSL supported by the client and the Cipher Suite list (encryption algorithm and key length).
- Step 2: When SSL communication is enabled, the Server responds with Server Hello packets. As with the client, the message contains the SSL version as well as the encryption component. The server’s encryption component content is filtered from the received client encryption component.
- Step 3: Then the server sends a Certificate packet. The message contains a public key certificate.
- Step 4: The Server sends a Server Hello Done packet to notify the client that the INITIAL SSL handshake negotiation is complete.
- Step 5: After the first SSL handshake, the Client responds with a Client Key Exchange packet. The packet contains a random password string called pre-master secret, which is used in communication encryption. The packet is encrypted with the public key in Step 3.
- Step 6: The client sends a Change Cipher Spec packet. The packet prompts the server that the communication after the packet is encrypted with the pre-master secret key.
- Step 7: The client sends a Finished packet. The packet contains the overall checksum of all packets so far connected. Whether the handshake negotiation can succeed depends on whether the server can decrypt the packet correctly.
- Step 8: The server also sends a Change Cipher Spec packet.
- Step 9: The server also sends a Finished packet.
- Step 10: After exchanging Finished packets between the server and client, the SSL connection is established. Of course, the communication is protected by SSL. This is where application layer protocol communication starts, that is, sending HTTP requests.
- Step 11: Application layer protocol communication, that is, sending HTTP responses.
- Step 12: Finally disconnect from the client. When the connection is disconnected, the close_notify packet is sent. After this step, a TCP FIN packet is sent to close the communication with TCP.
See diagram HTTP