The introduction of

The use of unencrypted plaintext in HTTP communication, such as entering a credit card number on a Web page, gives the credit card number away if the line of communication is bugged. In addition, in the case of HTTP, there is no way for the server or client to identify the communication party. It is possible that you are not actually communicating with the intended party. You also need to consider the possibility that the received message has been tampered with during communication. In order to solve these problems, encryption and authentication mechanisms need to be added to HTTP. We call HTTP with encryption and authentication mechanisms HTTPS (HTTP Secure).

HTTPS

HTTPS is not a new protocol at the application layer. The HTTP communication interface is replaced by SSL (SecureSocket Layer) and TLS (Transport Layer Security) protocols. Typically, HTTP communicates directly with TCP. When SSL is used, it evolves to communicate with SSL first and then with SSL and TCP. In short, HTTPS is HTTP in the shell of THE SSL protocol. With SSL, HTTP has the encryption, certificate, and integrity protection features of HTTPS. SSL is independent of HTTP. Therefore, SSL can be used with other protocols, such as SMTP and Telnet, that run on the application layer. SSL is the most widely used network security technology in the world today.

The encryption algorithm

SSL uses a type of encryption called public-key cryptography.

Shared key encryption

Encryption and decryption using the same key is called Common key cryptosystem, also known as symmetric key encryption. (== In shared key mode, you must send the key to the peer party. But how do you do it safely? When a key is forwarded over the Internet, if the communication is monitored the key can fall into the hands of an attacker, thus losing the purpose of encryption. You also have to secure the keys you receive. = =)

Public-key encryption

Public-key encryption: The sender uses the public key of the other party to encrypt the ciphertext. After receiving the encrypted message, the other party uses its private key to decrypt the encrypted message. In this way, there is no need to send the private key for decryption, and there is no need to worry about the key being eavesdropped and stolen by an attacker.

contrast

Public key encryption is slower than shared key encryption.

HTTPS uses a mixture of shared key encryption and public key encryption

Make full use of their respective advantages and combine a variety of methods for communication. Public key encryption is used in the key exchange and shared key encryption is used in the subsequent stage of establishing communication exchange messages.

A certificate certifying the correctness of a public key

Problems with public-key encryption: It is impossible to prove that the public key itself is a genuine public key. For example, how to prove that the public key received is the public key issued by the intended server when you are trying to establish public-key encryption communication with a certain server. Perhaps the real public key has been replaced by an attacker during the public key transfer.

To solve

A public key Certificate issued by a DIGITAL Certificate Authority (CA) and its related authorities. (A DIGITAL ca is in the position of being a trusted third party on both the client and the server.)

The working process

The server operator applies for a public key from a digital certificate Authority. After identifying the identity of the applicant, the digital certificate Authority will digitally sign the applied public key, allocate the signed public key, and bind the public key into the public key certificate.

The server sends the public key certificate issued by the Digital Certificate Authority to the client for public key encryption communication. Public key certificates can also be called digital certificates or simply certificates.

The client receiving the certificate can use the public key of the DIGITAL certificate Authority to verify the digital signature on the certificate. Once the authentication is successful, the client can know two things: first, the public key of the authentication server is a real and valid digital certificate authority. Second, the server’s public key is trustworthy.

The public key of the authentication authority here must be securely transferred to the client. When using communication methods, it is difficult to secure the transfer, so most browser developers release versions with the public key of the common authentication authority embedded beforehand.

Secure communication mechanism of HTTPS

== 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. = =

== In the preceding process, the application layer attaches a message digest called MAC when sending data. The MAC checks whether packets are tampered to protect packet integrity. = =

Why not use HTTPS all the time

If HTTPS is so secure, why don’t all Web sites use HTTPS all the time? One reason is that encrypted communication consumes more CPU and memory resources than plain text communication. If every communication is encrypted, it consumes a considerable amount of resources, and the number of requests that can be processed on a single computer is bound to decrease. Therefore, HTTP is used for non-sensitive information and HTTPS is used for encrypted communication only when sensitive data such as personal information is included. Especially when the most visited Web sites in the encryption process, they bear the load should not be underestimated. When encrypting, not all content is encrypted, but only those that need to be hidden to save resources.

Brief description of working principle

How HTTPS works

1. The Client accesses the Server using the HTTPS URL and requires an SSL connection with the Server
2. The Server returns the pre-configured public key certificate to the client.
3. Client authenticates the public key certificate: For example, whether the certificate is within the validity period, whether the certificate is used to match the site requested by the Client, whether the certificate is in the CRL revocation list, and whether its upper certificate is valid is a recursive process until the Root certificate (the Root certificate built into the operating system or the Root certificate built into the Client) is verified. If the verification passes, continue; if the verification fails, a warning message is displayed.
4. The Client uses the pseudo-random number generator to generate a symmetric key for encryption, encrypts the symmetric key with the public key of the certificate, and sends the symmetric key to the Server.
5. The Server decrypts the message using its own private key to obtain the symmetric key. At this point, both the Client and Server have the same symmetric key.
6. The Server encrypts plaintext A with the symmetric key and sends it to the Client.
7. The Client decrypts the ciphertext of the response using the symmetric key and obtains plaintext A.
8. The Client initiates an HTTPS request again, encrypts plaintext B with the symmetric key, and the Server decrypts the plaintext using the symmetric key to obtain plaintext B.

See diagram HTTP