Front knowledge

Symmetric encryption

Simple encryption, using the same key for encryption and decryption

The big question is how can this key be known to both parties without being known to anyone else

Asymmetric encryption

There are two keys, usually a public key and a private key. The contents encrypted with the public key can only be unlocked by the private key, and the contents encrypted with the private key can only be unlocked by the public key. Asymmetric encryption takes longer than symmetric encryption.

The digital certificate

Before HTTPS can be enabled, our server needs a certificate.

The certificate consists of two parts:

  • Plaintext information: public key, domain name, certificate signing algorithm, expiration time and other information
  • Digital signature: The result of converting plaintext information into a digest (binary number) using a certificate signing algorithm and encrypting the digest with the CA’s private key

Certificates can be obtained in two ways:

  1. Go to Ali cloud to buy and download, personal trial free.
  2. Locally generated using a command line tool, for example:
openssl genrsa -des3 -out sgfblog.com.key 1024
openssl req -new -key sgfblog.com.key -out sgfblog.com.csr
openssl rsa -in sgfblog.com.key -out sgfblog.com.nopass.key
Copy the code

The main process

First handshake

Client: hi, this is A random string client_random_string_1 generated locally and can support encryption algorithm A~D, you choose A encryption algorithm and let me know.

Second handshake

Server: Ok. I have saved client_random_string_1 locally. I have chosen A encryption algorithm. The following is the random string server_random_string_1 generated by me and my certificate. Please note that check ~

Third handshake

Client: Received. Let me verify the validity of this certificate first.

First, I use the public key provided by the CA organization to decrypt the digital signature in the certificate and get the information summary A. Then use the certificate signature algorithm mentioned in the certificate to encrypt the plaintext information to obtain B, and compare A and B to determine whether the certificate is tampered.

If tampering has not occurred, the domain name in the certificate is also compared to the currently requested domain name to ensure that the certificate has not been swapped.

After all the above verification, THE public key I get from the certificate is public_key. I have generated a random string client_random_string_2 again and encrypted it with public_key to form a secret_key. I have sent it to you, please check ~

subsequent

After receiving the encrypted secret_key, the server can decrypt it with its own private key, resulting in client_random_string_2.

At this point, the three handshakes are complete. Client and server both use client_random_string_1 + client_random_string_2 + server_random_string_1, in conjunction with encryption algorithm A, Locally generate a symmetric key symmetric_key. In this case, the symmetric_key of the client and server can be the same. The symmetric_key is used for encryption and decryption in subsequent communications.

The illustration

Small theater

Why do you need to generate an additional symmetric key?

Client: dude, I have the public key, and you have the private key. Can’t we just use this pair of asymmetric keys for encryption and decryption? Why do you need to generate an additional symmetric key?

Server: Both the public and private keys are stored on my side. How can I ensure that the public key transferred is not stolen by a middleman? Since there is no guarantee that the public key of confidentiality, then we can use the public key to encrypt a string, the string so only with my private key can decrypt, only heaven knows earth knows you know I know, let’s cooperate this string to a symmetric key generated, so that you can guarantee the safety of the symmetrical secret key. Also, symmetric encryption performs better.

Why do you need three random numbers to generate a symmetric key?

Client: I agree with the above point, but I still have a question: why do I need three random numbers to generate a symmetric key? Can’t I just use the last encrypted random string to generate it?

Server side: This way to ensure more security, whether the client or server, need random numbers, so that the generated key is not the same every time. Because SSL certificates are static, it is necessary to introduce a randomness factor to ensure the randomness of the negotiated keys. The SSL protocol does not trust that each host can generate a completely random number. If the random number is not random, the third random number may be guessed, so it is not appropriate to use only the third random number as the key. Therefore, a new random factor must be introduced. It is not easy to guess the key generated by two random numbers on the client and one random number on the server. A pseudorandom may not be random at all, but three pseudorandom will be very close to random. Every increase of one degree of freedom, the randomness will not increase by one.

Can the contents of the certificate be tampered with?

By chance, the middleman learns of a major transaction between the client and the server, and tries to steal trade secrets by tampering with certificates to disguise himself as the server. During the second handshake, the middleman intercepts the contents of the certificate, directly modifies the plaintext information on the certificate, and replaces the public key with his own, in an attempt to get away with it.

After receiving the certificate, the client verifies the digital certificate. In this case, the digital signature on the certificate does not correspond to the plaintext information. The middleman’s operation ended in failure.

The middleman tries again. This time, he not only modifies the plaintext message, but also converts the new plaintext message into a new digital signature with his private key (the middleman does not have the CA’s private key) and the signature algorithm, thus replacing the original digital signature.

After receiving the certificate, the client still authenticates the digital certificate. In this case, the client uses the CA’s public key to decrypt the digital signature in the certificate, but finds that the plaintext does not match the digital signature again. The middleman’s operation ended in failure.

Can the certificate be swapped?

The broker was defiant. The fake certificate generated by myself is not good, so I can replace it with a real valid certificate, right?

Client said: guy hit, you are still too young. In the process of decrypting the certificate, I will check whether the domain name recorded in the certificate is consistent with the domain name I really requested. One domain name corresponds to one certificate, but the result is definitely inconsistent. Finally, the middleman failed again.

Can random strings be tampered with?

Middleman still refuse to accept, wish since can’t disguise the server, that I disguise the client to try. The two random strings generated by the client are replaced with my own, so I can disguise the client.

The middleman is flattered while the client has set up an HTTPS link with the server. But in the end, he can only understand what the server is saying, and the middleman can’t understand what the client is saying. Because the random number of the client is different from that of the middleman, the symmetric key generated at last is different. Therefore, the natural middleman cannot decrypt the message of the client, and finally fails.