Why you don't understand HTTPS

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

Looking at the comments and private messages, I found that many people still don't understand HTTPS. I roughly analyzed it and found that the reason why HTTPS is difficult to understand is often because people fail to distinguish between the trunk and branches.

The backbone of HTTPS is very simple, it only has three layers.

First floor

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

Again, both parties hold a secret key for symmetric encryption, secure communication, and that's it.

What is this secret key?

1. The client can come up with a solution on its own and then pass it to the server.

2. The server can also come up with an answer on its own 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 used, the ultimate goal is to let both parties negotiate a same secret key, and then use it to symmetrically encrypt communications, which will make it safe.

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

But the logic of a lot of articles nowadays is to throw out a bunch of concepts for you to digest.

Symmetric encryption, asymmetric encryption, public key, private key, encryption, signature, summary, certificate, CA agency, middleman, etc.

Then you don’t even know what HTTPS is for, and you’re confused by these terms.

Let me say it one last time. What HTTPS does is to let both parties negotiate a common secret key, and then perform symmetrical encryption, and then the secure communication is completed.

Remember this first before moving on, because all other fancy operations are just to achieve this simple little goal.

So what’s the problem with negotiating the same secret key?

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

Then just make this process into ciphertext, and it has to be a ciphertext that the middleman cannot decipher.

This brings us to the second level.

Second floor

This is where asymmetric encryption comes in.

There are two types 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, and then I used the public key to encrypt the symmetric encryption key that I wanted to send to the server.

What is transmitted at this time is encrypted data, and only the server can decrypt it with a private key, and the middleman cannot know it.

OK, this step means that as long as the server successfully sends its public key to me, the rest will go smoothly.

However, the public key is also transmitted in plain text in this step, but it is an improvement compared to the beginning.

Because the transmission of secret keys is afraid of being seen by others and tampered with by others.

But at this point the public key is no longer afraid of being seen by others. If they see it, they can see it. Even if you know the public key, you cannot decrypt 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 by tampering. The process is very simple, so I will just post the picture from the previous article.

picture

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

The middleman's goal is to find out your secret key, nothing else matters.

Never forget your original goal.

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

Third floor

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

I can 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, so it cannot be tampered with. Even the middleman doesn't know what the public key is. It's perfect.

But the process of giving the public key to the server becomes plain text and can be easily tampered with. 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 pass it to the server.

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

That can...

You have discovered this, it's a nesting doll. There will always be a first time plain text content that will be tampered with by the middleman.

How to eliminate the embarrassment of the first time writing in plain text?

CA agency.

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

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

Then this encrypted 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 again with the CA's private key, but this is impossible as long as the CA is not a bad guy.

This ensures that the public key transmitted in plain text for the first time can only be viewed but cannot be tampered with.

So the middleman can only watch a public key that he knows being transmitted from the server to the client.

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

Therefore, the client and the server have a symmetric key that the middleman does not know and cannot decipher.

After that everything is OK.

Summarize

To sum it up.

The first layer: The communication between the two parties is simple symmetric encryption communication.

The second layer: https only solves how to securely 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 of asymmetric encrypted public key transmission is the asymmetric encryption of the CA organization (private key encryption and public key decryption: signature).

I think the others are not the main body, but side details.

Let’s look at the nouns mentioned above.

Symmetric encryption, asymmetric encryption, secret key, public key, private key, encryption, signature, summary, certificate, CA agency, middleman.

How do you string them all together? It's very simple.

Symmetric encryption is an algorithm that has only one secret key.

Asymmetric encryption is also an algorithm with 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 passes it over. This is the purpose.

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

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

picture

Another term is hash summary, which is also an algorithm. Its characteristics are that it can only be pushed forward, not backward, and no matter how large 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 used without it.

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

picture

Look at this step. It is okay without the hash summary. However, on the one hand, it will cause time problems when the CA private key encrypts long texts. On the other hand, it will cause the client to verify the entire information of the two large certificates, which is a waste.

For example, when we download a file, the hash value of the file will be verified to see if there are any changes during the download process.

In fact, this is just for the convenience of verification, so I said it is a branch in HTTPS, not the main knowledge.