The principle of HTTPS: public key encryption and private key decryption

Reprinted Why can’t the public key be used to encrypt with the public key? (qq.com)

Were you as confused as I was when you first came into contact with HTTPS?

The concept of this thing is many and cumbersome. Especially the public key and private key inside.

At that time, I really wanted to know, why can’t I use the public key to encrypt but not decrypt it?

After reading this article, you will figure it out, and at the same time unlock a lot of detailed knowledge points in HTTPS.

Today, let’s start with symmetric encryption and asymmetric encryption.

Symmetric and asymmetric encryption

When you were in primary school, you passed small notes, right? When passing the note, every student who got the note couldn’t help but glance at it, There is no privacy at all.

Suppose Banhua wants to confess her love to me, but she doesn’t want others to discover her affection in the process of spreading it.

He would tell me during the ten minutes between classes, “Move each letter one bit to the left, that’s what I want to say to you“.

Then when I was in class, I handed out a note with eb tib cj written on it. After reading the note, every classmate who helped pass the note cursed secretly, “Riddler, get the hell out of Gotham.”

Hey, you don’t understand, I understand.

After I got the note, I shifted each letter one bit to the left to get da sha bi.

What words, what words are these.

The bad woman wants to destroy my heart of Taoism? I decisively rejected her confession.

Looking back now, when I am moved, I will find that, like this, a piece of information that everyone can understand (plaintext) is converted into another piece of information that everyone cannot understand (ciphertext< /strong>), which is encryption.

This “left shift” encryption method is actually the so-called secret key. And this encryption and decryption use the same key encryption form, which is called symmetric encryption.

Image

? Symmetric encryption

Since there is symmetric encryption, there is asymmetric encryption.

The difference is that in asymmetric encryption, encryption and decryption do not use the same secret key, but two different secret keys, which are public key and private key >.

Image

? Asymmetric encryption

The public key is responsible for encryption and the private key is responsible for decryption. The public key is available to everyone, and the private key will never be revealed.

Then the problem comes.

Why is it encrypted with the public key but not decrypted with the public key?

This actually involves the mathematical principles of public key and private key encryption.

To put it bluntly, encryption is to convert a known number according to certain rules into another number. In the past, these numbers were readable together, but after such a conversion , becomes unreadable.

That is to say, the essence of encryption is num -> x (num is a known number, x is an unknown number).

For example, the sender adds 1 to 34 to get 35, and the receiver subtracts 1 from 35 to get 34

Now use the modulo operation.

Original text^(p*q) mod N = original text

If p, q, and N are selected correctly, the original text will return to the original text after a wave of modulo operations.

Knowing this is useless, but combined with Euler’s theorem, and after some derivation process that we can’t understand, the above formula can be transformed into the following.

Original text^(p) mod N = cipher text
Ciphertext^(q) mod N = original text

If you are interested in the calculation process combined with Euler’s formula, you can look it up. But it is enough to know the conclusion here.

That is to say, if you know p, you can encrypt it, and if you know q, you can decrypt it.

Here, p is the public key, and q is the private key.

The ciphertext encrypted with the public key can only be decrypted with the private key.

Image

? Encryption and decryption formula

And even better.

In fact, the positions of p and q in the formula are interchangeable, so conversely, “The ciphertext encrypted with the private key can only be decrypted with the public key“, also ok. And this kind of operation is often said to verify digital signature.

It’s like the old costume TV dramas in the past, there are often such plots, two relatives who have been separated for many years, each wearing a a jade pendant broken into two parts. One day they found that the cracks in the two jade pendants fit together, and they confirmed that the other party was their long-lost brother.

These two pieces of broken jade are a bit like public key and private key.

image

? The relationship between public key and private key

The principle is that everyone knows that much is actually enough.

The encryption principle of HTTPS

If you do development on the company’s intranet, and the code you write only provides services to the intranet. Then there is a high probability that your service uses the HTTP protocol.

But if one day you want friends on the external network to experience your service functions, you need to expose the service to the external network, and if you still use the HTTP protocol at this time, the information will be sent and received in plain text, as long as Interested people can see the content in your HTTP packet by grabbing a packet from any router in the communication link, so it is very unsafe.

In order to turn the plaintext into ciphertext, we need to add a layer of TLS on top of the HTTP layer for the purpose of encryption. This has become what we often call HTTPS.

image

TLS is actually divided into 1.2 and 1.3 versions. At present, the mainstream version is still 1.2. Let’s take it as an example to see how the HTTPS connection is established.

HTTPS handshake process

The first is to establish a TCP connection. After all, HTTP is an application layer protocol based on TCP.

After the TCP protocol is successfully established, the encryption process of HTTPS can begin.

In general. The entire encryption process is actually divided into two stages.

Image

? Two-stage encryption

The first stage is the TLS four-way handshake. This stage mainly uses the characteristics of asymmetric encryption to exchange information, and finally obtain a “session key”.

The second stage is to carry out symmetric encryption communication on the basis of the “session key” in the first stage.

Let’s first look at what the TLS four-way handshake looks like in the first phase.

image

? HTTPS process

First handshake:

  • Client Hello: The client tells the server what encryption protocol version it supports, such as TLS1.2, and what encryption suite to use, such as the most common RSA, and a client random number is also given.

Second handshake:

  • Server Hello: The server tells the client, Server random number + server certificate + determined encryption protocol version (for example, TLS1.2).

Third handshake:

  • Client Key Exchange: At this time, the client generates a random number called pre_master_key. Take out the server public key from the server certificate in the second handshake, encrypt pre_master_key with the public key, and send it to the server.
  • Change Cipher Spec: The client side already has three random numbers: client random number, server random number and pre_master_key, use these three random numbers to get a “Session Key“. At this time, the client notifies the server, and this session key will be used for symmetric and confidential communication later.
  • Encrypted Handshake Message: The client will generate a summary of the communication data so far, encrypt it with “session key“, and send it to the server for verification. At this point, the handshake process on the client side is over, so it is also called the Finished message.

The fourth handshake:

  • Change Cipher Spec: The server gets the pre_master_key from the client at this time (although it is encrypted by the server’s public key, the server has a private key and can decrypt it to get the original text) , collect three random numbers, and use these three random numbers to obtain a “session key” through the same algorithm as the client. At this time, the server tells the client that this “session key” will be used for encrypted communication later.
  • Encrypted Handshake Message: Same as the operation of the client, generate a summary of the content of the communication data so far, encrypt it with “session key“, and send it to the client Do the verification. At this point, the handshake process of the server is also over, so this is also called the Finished message.

Just a few handshakes are full of details, and nothing is superfluous.

Let’s explain one by one.

Because everyone must be very dizzy, so I will try to use short sentences to explain the following questions.

Is HTTPS symmetric encryption or asymmetric confidentiality?

Used both. The 4 handshakes in the early stage are essentially using the characteristics of asymmetric encryption to exchange three random numbers.

The purpose is to finally use these three random numbers to generate a symmetrically encrypted session key. In the later stage, communication has been carried out in a symmetrical and confidential manner.

image

Why not use asymmetric encryption?

Because asymmetric encryption is slow, symmetric encryption is relatively faster.

What is the server certificate in the second handshake? How to get the public key out of it?

A server certificate is essentially a server public key encrypted by a authoritative digital certificate authority (CA) private key.

Image

As mentioned above, The data encrypted by the private key can be decrypted by the public key. The public key is available to anyone. So during the second handshake, the client can use the CA’s public key to decrypt the server certificate and get the hidden server public key.

image

Seems a bit redundant?

So here comes the problem.

Why can’t I just pass the public key, but encrypt it with the private key of the CA before passing it?

Thinking about it the other way around, if only the public key is transmitted, the public key may be replaced by hackers during the transmission. Then during the third handshake, the client will take the fake public key to encrypt the third random number pre_master_key, and the hacker will know it after decrypting it The most critical pre_master_key. And because the first and second random numbers are public, the “session key” can be calculated.

So there needs to be a way to prove that the public key obtained by the client is the real server public key, so we use the CA’s private key to encrypt it once and become The server certificate, so that the client can decrypt the CA’s public key to verify whether it is the real server public key.

Then the problem arises again

How to get the public key of CA?

The easiest thing to think of is to request the official website of the CA to obtain the public key. But there are so many people in the world who want to go online, if they all use it to request the official website of CA, the official website will definitely not be able to withstand it.

Considering that there are not many CA institutions that can issue certificates, so there are not many corresponding CA public keys. Put them directly as configuration into the operating system or browser, which perfectly solves the above problem .

Image

Can others not get your three random numbers?

Of these three random numbers, two are from the client and one is from the server. Both the client random number and the server random number in the first and second handshakes are in plain text. As long as the heart is willing, everyone can get it.

But the third random number pre_master_key does not work, because it is encrypted by the server’s public key after it is generated by the client and before it is sent to the server, so only the server itself Only then can the private key be used for decryption. Even if it is obtained by others, without the private key of the server, the original text cannot be decrypted.

Image

Why use three random numbers? Instead of one or two?

image

It seems that the third random number pre_master_key is the key, and the other two seem to be dispensable?

Indeed, even without the other two, it does not affect the encryption function. The reason why two random numbers are needed is because only a single pre_master_key is not random enough, and the secret key that may come out in the case of multiple randomizations is the same. However, if two more random numbers are introduced, the degree of randomness of “session key” can be greatly increased, thereby ensuring that the session key used for each HTTPS communication is different.

Why is there a summary for the third and fourth handshakes?

At the end of the third and fourth handshakes, there is a Finished message, which contains a digest.

Summary, to put it bluntly, is to perform a hash operation on a large piece of text. The purpose is to confirm that the data has not been tampered with during the communication.

In the third handshake, the client generates a summary, and the server verifies. If the verification passes, it means that the data generated by the client has not been tampered with, and the server can rest assured to communicate with the client.

The fourth handshake is reversed. The server generates a summary and the client verifies it. If the verification passes, it means that the server is trustworthy.

So here comes the problem.

Why do you want to hash once instead of directly comparing the original text?

This is because the content of the original text is too long, and the data can be shortened after hashing. Shorter means less transmission cost.

image

How many pairs of private keys and public keys are involved in this process?

two pairs.

The server’s own public key and private key: In the second handshake, the server sends its own public key (hidden in the digital certificate) to the client. This server public key is used in the third handshake to encrypt the third random number pre_master_key. After getting it, the server uses its own private key to decrypt it.

CA’s public key and private key: In the second handshake, the transmitted digital certificate contains the server’s public key encrypted by CA’s private key. After the client gets it, it will use the CA public key built into the operating system or browser to decrypt it.

Summary

  • The modulo operation of large numbers is irreversible, so others cannot decrypt it violently. But combined with Euler’s theorem, we can select the appropriate p (public key), q (private key), N (large number for modulus), so that the original irreversible operation can be performed in a specific situation Next, it becomes a bit “reversible”. Mathematical principles determine that the data we encrypt with the public key can only be decrypted with the private key. Conversely, the data encrypted with the private key can only be decrypted with the public key.
  • HTTPS is equivalent to HTTP + TLS. The current mainstream is TLS1.2, which is based on the three-way handshake of TCP, followed by the four-way handshake of TLS.
  • Two pairs of private keys and public keys are involved in the TLS four-way handshake. They are the private key and public key of the server itself, and the private key and public key of the CA.
  • It will be quite uncomfortable to memorize the four-way handshake of TLS. It is recommended to pay attention to the flow of the three random numbers, and use this as a basis to understand, and you can probably remember it.
syntaxbug.com © 2021 All Rights Reserved.