Shulou(Shulou.com)11/24 Report--

When you first came into contact with HTTPS, you were as confused as I was.

This thing is full of concepts and tedious. Especially the public key and private key in it.

At that time, I particularly wanted to know why encryption with the public key could not be decrypted with the public key.

After reading this article, you will understand and unlock a lot of detailed knowledge points in HTTPS.

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

Symmetric encryption and asymmetric encryption in primary school classes, have you passed a small note? When passing the note, every student who gets the note can't help but take a look at it. There is no privacy at all.

Suppose the class flower wants to express her love to me and doesn't want others to find her affection in the process of passing it on.

He would tell me in ten minutes at recess, "move one letter to the left, that's what I want to say to you."

Then in class, hand out a note with eb tib cj written on it. Every student who helped pass the note read it and scolded "Riddler, you get out of Gotham Town".

Hey, hey, you don't understand, I do.

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

What are you talking about? what are these words?

Is the bad woman trying to destroy my heart to Tao? I refused her confession decisively.

When I recall it now, when I am moved, I will find that, like this, converting a piece of information (plaintext) that we can understand into another message (ciphertext) that we do not understand is actually encryption.

Encryption methods like this "shift to the left" are actually the so-called secret keys. This kind of encryption and decryption use the same secret key encryption form, which is called symmetrical encryption.

Symmetric encryption. So since there is symmetric encryption, then there is asymmetric encryption.

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

The asymmetric encryption 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 is never disclosed.

Then here comes the problem.

Why is it encrypted with the public key but not decrypted with the public key? This actually involves the mathematical principle of public key and private key encryption.

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

In other words, the essence of encryption is num-> x (num is known, x is unknown).

For example, the operation of the class flower plus one minus one is a very simple way of conversion.

Then let's change to something complicated, such as a remainder operation.

Suppose there is a formula for congruence.

The formula 5 ^ 2 mod 7 = 25 mod 7 = x is very simple. When the sum of 5 to the power of 2 and 7 is known, it is easy to get xtriple 4.

But if we change the position of x.

5 ^ x mod 7 = 4 when finding how much x equals, does the above equation hold?

That would be a lot of trouble.

5 ^ 0 mod 7 = 15 ^ 1 mod 7 = 55 ^ 2 mod 7 = 45 ^ 3 mod 7 = 65 ^ 4 mod 7 = 2 although it is a bit troublesome, it can still be deduced that the equation holds.

But what if the modular numbers above become huge?

5 ^ x mod 56374677648 = 4 then the computer can only try it out one by one. It takes many years for a normal CPU to be calculated, so it can be considered that it cannot be calculated.

In fact, the above formula is to encrypt 5 to 4. If x is known, it is easy to calculate that the result on the right side of the equation is 4, but conversely, it is difficult to deduce the value of x from 4. Therefore, such a modular algorithm is irreversible.

Although the modular operation is irreversible, combined with the Euler theorem, we can make the formula a little "reversible" under certain conditions (note that it is in quotation marks).

Let's see how it's done.

We break x into two pieces and turn it into the product of p and Q.

If p, Q, N are selected properly, the original text will be changed back to the original text after a wave of modular operation.

It's useless to know this, but combined with Euler's theorem, and through some derivation that we don't understand, we can transform the above formula into the following.

The original text ^ (p) mod N = ciphertext ^ (Q) mod N = the calculation process of the original text combined with Euler formula can be checked if you are interested. But it's enough to know the conclusion here.

In other words, if you know p, you can encrypt it, and if you know Q, you can decrypt it.

And here p is the public key and Q is the private key.

Ciphertext encrypted with a public key can only be decrypted with a private key.

Encryption and decryption formula, and even better.

In fact, the positions of p and Q are interchangeable in the formula, so on the contrary, "ciphertext encrypted with a private key can only be decrypted by a public key", which is also ok. And this kind of operation is often said to verify the digital signature.

This is like in the previous costume TV series, there is often such a plot, two relatives who have been separated for many years, each with a piece of broken jade wear. One day they found that the two cracks in the jade dress could be put together, so they confirmed that the other side was the good son they had lost for many years.

These two pieces of broken jade have the taste of public key and private key.

It is enough to know so much about the principle of the relationship between public key and private key.

Seeing here, we can answer the question in the title.

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

Because the modular operation of large numbers is irreversible, it is impossible for others to decipher it violently. But combined with Euler theorem, we can select the appropriate p (public key), Q (private key), N (large number used to take module), so that the originally irreversible operation becomes a little "reversible" under certain circumstances. The mathematical principle determines that the data we encrypt with the public key can be decrypted only by the private key. Conversely, only the public key can decrypt the data encrypted with the private key.

From the mathematical principle, we can also see that public key and private key encryption is secure, but the premise of this matter is that "the computing speed of today's computer is not fast enough". Therefore, if one day science and technology becomes more developed and we become a higher-dimensional scientific and technological civilization, the ciphertext may be no different from the plaintext.

Now that we know about symmetric encryption and asymmetric secrets, we can talk about the encryption principles of HTTPS.

The encryption principle of HTTPS if you develop in the company's intranet, and the code you write only provides services to the intranet. There is a good chance that your service is using the HTTP protocol.

But if one day you want your friends in the public network to experience your service features, you need to expose the service to the public network. At this time, if you still use the HTTP protocol, the message will be sent and received in plaintext. As long as the interested person grabs a packet in any router in the communication link, you will be able to see the contents of your HTTP packet, so it is very insecure.

In order to make plaintext into ciphertext, we need to add a layer of TLS on top of the HTTP layer in order to do encryption. This is what we often call HTTPS.

TLS is actually divided into 1.2 and 1.3. at present, the mainstream is still 1.2. let's take it as an example to see how the connection to HTTPS is established.

The first step in the HTTPS handshake process is to establish a TCP connection. After all, HTTP is an application layer protocol based on TCP.

After TCP successfully establishes the protocol, you can begin to enter the encryption process of HTTPS.

All in all. The whole encryption process is actually divided into two stages.

The first stage of encryption is TLS four-way handshake, which mainly uses the characteristics of asymmetric encryption to exchange information and finally get a "session key".

The second stage is to carry out symmetrically encrypted communication on the basis of the "session key" of the first stage.

Let's take a look at what the first phase of the TLS four-way handshake looks like.

First handshake in the HTTPS process:

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

Second handshake:

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

Third handshake:

Client Key Exchange: at this time, the client is regenerated into a random number, called pre_master_key. Take the server public key from the server certificate of the second handshake, encrypt the pre_master_key with the public key, and send it to the server.

Change Cipher Spec: there are already three random numbers on the client side: client random number, server random number and pre_master_key. Use these three random numbers to calculate a "session key". At this point, the client notifies the server that the session key will be used for symmetric secret communication later.

Encrypted Handshake Message: the client will generate a summary of the communication data so far, encrypt it with the "session key" and send it to the server for verification. At this time, the handshake process on the client side ends, so it is also called Finished message.

Fourth handshake:

Change Cipher Spec: at this time, the server gets the pre_master_key from the client (although it has been encrypted by the server public key, but the server has a private key and can decrypt the original text), sets three random numbers, and uses these three random numbers to obtain a "session key" through the same algorithm as the client. At this point, the server tells the client that the session key will be used to encrypt the communication later.

Encrypted Handshake Message: like the operation of the client, generate a summary of the communication data so far, encrypt it with the "session key", and send it to the client for verification. At this point, the handshake process on the server ends, so this is also called Finished message.

Just a few handshakes, full of details, none of them 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 secret? It's all in use. The previous four-way handshake is essentially an exchange of three random numbers by making use of the characteristics of asymmetric encryption.

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

Symmetric encryption or asymmetric encryption? why not all use asymmetric encryption? Because asymmetric encryption is slow, symmetric encryption is relatively fast.

What is the server certificate in the second handshake? How do I get the public key out of it? The server certificate, in essence, is the server public key encrypted by the private key of the authoritative digital certificate authority (CA).

What is the server certificate mentioned above? data encrypted by the private key can be decrypted with the public key. And the public key is available to anyone. So during the second handshake, the client can decrypt the server certificate through the CA public key and get the server public key hidden inside.

Decrypting the certificate with the CA public key seems a bit superfluous?

So here comes the question.

Why can't I just pass the public key and encrypt it again with the private key of CA? On the other hand, if only the public key is passed, the public key may be replaced by the hacker in the process of transmission. Then the client will encrypt the third random number pre_master_key with a fake public key during the third handshake, and the hacker will naturally know the most critical pre_master_key after decryption. And because the first and second random numbers are public, the "session key" can be calculated.

So we need a way to prove that the public key obtained by the client is the real server public key, so we encrypt it with the private key of CA and become the server certificate, so that the client can decrypt it with the public key of CA and verify whether it is the real server public key.

Then there's the problem again.

How to get the public key of CA? The easiest thing to think of is to request the official website of CA to get the public key. But there are so many people who want to surf the Internet all over the world, if they all use to request the official website of CA, the official website will certainly not be able to stand it.

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

If the CA public key is embedded in the operating system or browser, other people can't get your three random numbers? These three random numbers, two from the client and one from the server. The client random number and server random number in the first and second handshakes are both plaintext. As long as you have the heart, everyone can get it.

But the third random number pre_master_key is not, 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 can decrypt it with the private key. Even if someone else gets it, it will not be able to decrypt the original text without the private key of the server.

Why use three random numbers to encrypt and decrypt pre_master_key? Instead of one or two?

Generating symmetric keys from three random numbers looks like the third random number pre_master_key is the key, and the other two look dispensable?

Indeed, even without the other two, it does not affect the encryption function. The reason for the need for two random numbers is that only a single pre_master_key is not random enough, and if it is random many times, the secret key may be the same. However, if two more random numbers are introduced, the degree of randomness of the session key can be greatly increased, thus 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 is a Finished message with a summary.

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

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

The fourth handshake, on the contrary, the summary is generated by the server, and the client verifies that the verification is passed, indicating that the server can be trusted.

So here comes the problem.

Why hash once instead of comparing the original text directly?

This is because the content of the original text is too long, and the data can be shortened after hash. Shorter means lower transmission costs.

How many pairs of private and public keys are involved in the algorithm? Two pairs.

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

CA's public and private keys: in the second handshake, the passed digital certificate contains the server's public key encrypted by CA's private key. After the client gets it, it will decrypt it with the CA public key built into the operating system or browser.

The modular operation of summing up large numbers is irreversible, so others cannot decipher it violently. But combined with Euler theorem, we can select the appropriate p (public key), Q (private key), N (large number used to take module), so that the originally irreversible operation becomes a little "reversible" under certain circumstances. The mathematical principle determines that the data we encrypt with the public key can be decrypted only by the private key. Conversely, only the public key can decrypt the data encrypted with the private key.

HTTPS is equivalent to HTTP+TLS, the current mainstream is TLS1.2, based on TCP three-way handshake, followed by TLS four-way handshake.

The TLS four-way handshake involves two pairs of private and public keys. They are the private and public keys of the server itself, and the private and public keys of CA, respectively.

TLS four-way handshake can be uncomfortable on the back. It is recommended to pay attention to the flow of three random numbers as a basis for understanding, and you can probably write it down.

This article comes from the official account of Wechat: rookie debug (ID:xiaobaidebug), author: Xiaobai

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.