This paper mainly briefly introduces the common encryption types, application scenarios, why digital signatures and certificates are needed, and the encryption process involved in HTTPS. From the user's point of view, the algorithm itself is not introduced too much.

Symmetric/asymmetric encryption belongs to reversible encryption, and ciphertext can be restored to plaintext by key.

Sometimes, we hope that once the plaintext is encrypted, no one (including ourselves) can push it back through the ciphertext. Irreversible encryption is to meet this demand.

Irreversible encryption is mainly realized by hash algorithm: that is, a hash value with a specific length is generated for the target data; Whether your data is 1KB, 1MB or 1GB, it will generate a hash value with a specific length (for example, 128bit). Everyone here should feel a little irreversible. The encrypted hash value of 128bit obviously cannot restore 1 G or even larger irregular data. Hash can be seen as a summary of the original content.

Common algorithms:

Xiao Ming wrote to Xiao Hong:

After nine to eighteen turns, the content of the letter may be: 1. Peeked at 2. Tamper (pretending to be Xiaoming and sending false messages):

Mr. Xiaohong generates a symmetric encryption key key 1, and then gives it to Xiao Ming through a secure channel.

When transmitting data, Xiaoming uses key 1 for encryption, and Xiaohong uses key 1 for decryption after receiving it.

At this time, the middleman can neither see the original content nor tamper with it (because there is no key):

Symmetric encryption has the advantages of simple implementation, excellent performance and high security level of the algorithm itself. However, the key management is a headache: once the key is given to the other party, we can't control the other party's ability to keep the key. Once the other party leaks, encryption is useless.

Relatively speaking, the asymmetric encrypted public key has no such worry, because the public key is designed to be public, and even if the other party leaks it, we will not lose anything.

Xiaohong generates a pair of public and private keys, holds the private key (pri_key 1) and gives the public key (pub_key 1) to Xiaoming.

When transmitting data, Xiaoming uses the public key to encrypt and Xiaohong uses the private key to decrypt.

Because the intermediary does not have a private key, it cannot obtain the content encrypted by the public key. At this time, the effect of preventing voyeurism is achieved:

But because the public key can be made public, if the intermediary knows the public key, although there is no way to see the original content, he can pretend to be Xiao Ming and send a fake message:

At this time, Xiaohong was thinking that if Xiao Mingcan brought data (character strings) that only he could generate when sending a message, I could verify whether this was the real message sent by Xiao Ming.

Usually, this kind of data (string) that can prove identity is called digital signature.

Xiaoming generates a pair of public and private keys, holds the private key (pri_key2) and gives the public key to Xiaohong (pub_key2).

When Xiao Ming transmits data (which may be very large), he should not only encrypt the plaintext with the public key, but also bring the signature: (1) make a hash summary of the plaintext; (2) Encrypt the abstract with the private key, and the encryption result is a signature (transmission content = content ciphertext+signature).

Xiaohong receives: (1) decrypt the signature to get a hash (2) decrypt the ciphertext of the content, and hash the decrypted plaintext; If the two hashes are consistent, the test is passed.

Although the intermediary modified the transmission content, Xiaohong failed to verify the signature because the signature could not be recognized (there was no private key), so naturally she would not recognize this data:

Usually, asymmetric encryption requires two pairs of public keys and private keys to prevent voyeurism and tampering: the other party's public key is used for content encryption and his private key is used for signature (allowing the other party to verify his identity).

Because of the security problem of plain text communication in HTTP protocol, HTTPS is introduced: by establishing a secure channel (connection), the security of data transmission is guaranteed.

The server can't directly transmit the key to the browser, because before the secure connection is established, all communication contents are plaintext, and the intermediary can peek at the key information.

Maybe you thought of asymmetric encryption at this moment, because the public key is not afraid of being made public:

However, in step 2, the intermediary can intercept the server's public key and replace it with its own public key, so encryption is meaningless:

In order to prevent the public key from being forged, digital certificates were born.

When the server needs to tell the browser the public key, it does not simply return the public key, but responds to the digital certificate containing the public key information.

The certificate mainly includes the following contents:

The browser decrypts and verifies the certificate through the public key of the issuing authority. If the certificate is verified, it shows the authenticity of the certificate, so you can safely obtain the public key of the certificate owner. (The public key of common CA institutions has been implanted in the browser)

Digital certificates only do one thing: make sure that the public key that the server responds to is true.

The above guarantee [browser? Server] is encrypted, but [server? Browser] but not (step 4 above); The other is the performance problem. If all data are asymmetrically encrypted, it will consume more server resources and the communication speed will be greatly affected.

HTTPS skillfully combines asymmetric encryption with symmetric encryption to improve performance as much as possible on the premise of ensuring communication security between the two parties.

HTTPS(SSL/TLS) hopes to communicate with symmetric encryption after establishing a secure connection.

The task of establishing a secure connection is to let the browser-server negotiate the symmetric encryption algorithm and key used in the connection; Asymmetric encryption and digital certificates will be used in the negotiation process.

It should be noted that the negotiated key must be hard to guess (random enough):

The core is the random number r3 (pre-master secret), because the previous r 1 and r2 are all plaintext transmission, and only r3 is encrypted transmission. As to why three random numbers are needed, please refer to:

The above is a relatively simple HTTPS process. Please refer to the quotation at the end of the article for details.

References:

[1] Comprehensive Secret of Digital Certificate Application

[2] Overview of the operating mechanism of SSL/TLS protocol

[3] Give an example of SSL/TLS protocol.

[4] "Graphic HTTP"