I wrote an article about HTTPS the day before yesterday. You call this crap HTTPS.

After reading the comment area and private messages, I found that there are still many people who don't understand HTTPS. I did a rough analysis and found that the reason why HTTPS is difficult to understand is often caused by the lack of distinction between trunk and branches.

The backbone of HTTPS is very simple, actually just three layers.

level one

The first layer is the backbone of the backbone. In one sentence, encrypted communication means that both parties hold a symmetrically encrypted secret key, and then they can communicate securely. It's that simple.

Once again, both parties hold a symmetrically encrypted secret key, and secure communication is over.

What is this secret key?

1. The client can think of one by itself and then pass it to the server.

2. The server can also think of one by itself and then pass it to the client.

3. Or both parties can think of a string of numbers and then combine them.

None of this matters. No matter how many tricks are played, the ultimate goal is for both parties to negotiate the same secret key and then use it to symmetrically encrypt the communication, which is safe.

I think if we talk about HTTPS from this simple starting point, no one will understand it.

But now the logic of a large number of articles is to throw out a bunch of concepts for you to digest.

Symmetric encryption, asymmetric encryption, public keys, private keys, encryption, signatures, digests, certificates, CA authorities, intermediaries, and more.

Then you don’t even know what HTTPS is for, so you are confused by these terms first.

One last time, what HTTPS has to do is to allow both parties to negotiate the same secret key, and then symmetrically encrypt it, and the secure communication is over.

Remember this matter first before moving on, because all other cool operations are just to accomplish this simple small goal.

So what's wrong with the process of negotiating the same secret key?

The problem is that whether the initial secret key is passed from the client to the server or from the server to the client, it is transmitted in clear text and can be known by the middleman.

Then just let this process become ciphertext, and it must be ciphertext that cannot be decrypted by the middleman.

This is the second level.

Second floor

This involves asymmetric encryption.

There are two methods of asymmetric encryption, public key encryption and private key decryption, and private key encryption and public key decryption.

What we need at this time is the first one.

The server threw its public key to me in plain sight, and then I used the public key to encrypt the symmetric encryption key I wanted to send to the server.

At this time, the encrypted data is transmitted, and it can only be decrypted by the server using the private key, and the middleman cannot know it.

OK, this step means that as long as the server successfully throws its public key to me, the rest will be a matter of course.

However, the public key in this step is also transmitted in clear text, but it has improved compared to the beginning.

Because the secret key transmission is not only afraid of being seen by others, but also afraid of being tampered with by others.

But at this time, the public key is no longer afraid of others seeing it. Just see it if you see it. Even if you know the public key, you can't decipher the secret key encrypted by the client with the public key.

However, there is still a fear of tampering.

The middleman can eventually obtain your secret key through tampering. This process is very simple, just like the picture in the previous article.

picture

Always remember that your ultimate goal is to negotiate a secret key to symmetrically encrypt communications.

The goal of the middleman is to find a way to know your secret key, and nothing else matters.

Never forget the original goal.

How to prevent this public key from being tampered with is the third layer.

the third floor

How can I prevent others from tampering with the public key given to me by the server?

I can first generate a pair of public and private keys myself, and then give the public key to the server. The server uses my public key to encrypt its public key. This way it cannot be tampered with, and even the middleman doesn't even know what the public key is. ,Perfect.

But the process of giving the public key to the server has become clear text again, and it is easy to be tampered with, so what should I do?

Then the server can give me the public key, and then I use this public key to encrypt my public key and send it to the server.

The public key the server gave me is in plain text and can easily be tampered with.

That can...

You've discovered this, it's like a matryoshka doll. There is always the first clear text content, which will be tampered with by the middleman.

How to eliminate the embarrassment of being explicit for the first time?

CA agency.

The CA organization also has a set of public and private keys.

The server gives its public key to the CA, lets the CA encrypt it with the CA's private key, and then returns the encryption result.

Then this encryption result can be decrypted using the CA's public key, and anyone can decrypt it.

However, if you want to tamper with the result, you must encrypt it with the CA's private key again, but this cannot be done as long as the CA is not a bad guy.

This ensures that the public key transmitted in clear text for the first time can only be seen and cannot be tampered with.

So the middleman can only watch as a public key he knows is passed from the server to the client.

The client then uses this public key to encrypt the subsequent symmetrically encrypted secret key and transmits it to the server. The middleman cannot decrypt it because he does not know the server's private key.

As a result, the client and server have a symmetric secret key that the middleman does not know and cannot unlock.

After that it's OK.

Summarize

To sum it up.

Layer 1: The communication between the two parties is simple symmetric encryption communication.

The second layer: https only solves how to safely transmit the symmetric encryption key to the other party, that is, using asymmetric encryption (public key encryption and private key decryption: encryption).

The third layer: How to prevent tampering in the public key transmission of asymmetric encryption, that is the asymmetric encryption of the CA organization (private key encryption and public key decryption: signature).

I don’t think the others are the backbone, they are all bypass details.

Look at the previous nouns again,

Symmetric encryption, asymmetric encryption, secret key, public key, private key, encryption, signature, digest, certificate, CA authority, middleman.

How to string them all together? Very simple.

Symmetric encryption is an algorithm with only one secret key.

Asymmetric encryption is also an algorithm. It has two secret keys. The one that is kept secret is called the private key, and the one that is made public is called the public key.

Public key encryption and private key decryption are called encryption. The client uses the server's public key to encrypt its own secret key and pass it over. This is the purpose.

Private key encryption and public key decryption are called signatures. The CA organization uses the private key to encrypt the public key information of the server to generate a signature. This is the process, and its purpose is to prevent tampering.

As mentioned in the previous article, this is like a magical dual-key lock.

picture

Another word is hash summary, which is also an algorithm. Its characteristic is that it can only be pushed forward, not backward, and no matter how big the original text is, the hash summary will be the same size. This is mainly used for verification. I think it is a branch, because it can be done without it.

For example, CA actually does not simply encrypt the public key of the server, but encrypts the hash digest of the certificate (in fact, the certificate is the public key of the server, plus some other information, such as the server domain name, issuing authority, etc. wait)

picture

If you look at this step, it's okay without the hash digest. However, on the one hand, it will cause a time problem when the CA private key encrypts long text. On the other hand, it will also cause the client to hold two large certificates when verifying. All information verification is very wasteful.

For another example, when we download a file, there will be a hash value of the file for verification to see if there is any change during the download process.

In fact, this is just to facilitate verification, so I said it is a branch in HTTPS and not the main body of knowledge.