HTTPS principle Popular Understanding

Summary: This article attempts to restore the HTTPS design process step-by-step to understand why HTTPS will eventually look like this. But this does not represent the true design process of HTTPS. When you read this article, you can try to put down the existing understanding of HTTPS, which is more beneficial to the "restore" process.

We're not going to talk first. Http,https, we start with a chat software, we want to achieve a can send a hello message to B:

If we want to implement this chat software, this article only consider security issues, to achieve

A to B's Hello message packet, even if the intermediary intercepted, also can not know the content of the message

How to achieve real security?

This problem, many people immediately think of a variety of cryptographic algorithms, what symmetric encryption, asymmetric encryption, DES, RSA, XX, crackling ~

And I want to say that the encryption algorithm is just a solution , and the first thing we need to do is to understand our problem domain - what is security?

My personal understanding is:

The content of A and B communication, and only A and B have the ability to see the true content of the communication

Well, the problem domain is already defined (and of course there is more than one definition in reality). For the solution, it's easy to think of encrypting the message.

Off-topic, but is there only one way? I don't think so, maybe in the future there will be a substance that breaks the current world of communication assumptions and achieves true confidentiality.

For simple communication models such as a and B, it's easy to make a choice:

This is the symmetric encryption algorithm , where the key s in the diagram play both the role of encryption and decryption. Details are not the scope of this article.

As long as the key S is not publicly available to the third party, and the key S is secure enough, we have solved the problem domain we set up at the outset. Because the world has and only A and b know how to encrypt and decrypt messages between them.

However, in the WWW environment, our web server communication model is not so simple:

If the server side uses the same symmetric encryption algorithm for all client communication, there is no encryption. What about that? is it possible to use a symmetric encryption algorithm without exposing the key? ask the reader to think for 21 seconds.??

The answer is: The Web server uses a different symmetric encryption algorithm for each client:

How to determine the symmetric encryption algorithm

Wait, another question, how does our server tell the client which symmetric encryption algorithm to use?

By negotiation, of course.

However, your negotiation process is not encrypted, or will be intercepted by the middleman. Then we will be symmetric encryption of this negotiation process is good, then you to the negotiation process encryption or encryption is not encrypted, how to do? Re-encryption is not good ... OK, let's have the chicken with the egg.

How to encrypt the negotiation process

New question, how to encrypt the negotiation process? In cryptography, there is a kind of encryption algorithm called "Asymmetric Encryption", which is characterized by secret key encryption, as long as the public key, can be decrypted, but the public key encrypted ciphertext, only the private key can be decrypted. The private key has only one person, and the public key can be sent to all people .

Although the server side to a, B ... Direction is still unsafe, but at least a, B to the server-side direction is secure.

OK, how to negotiate the problem of encryption algorithm, we solved: Using asymmetric encryption algorithm for symmetric encryption algorithm negotiation process.

Now, do you understand why HTTPS requires both symmetric and asymmetric encryption algorithms?

Negotiate what encryption algorithm

To achieve a Web server to use a different symmetric encryption algorithm for each client, at the same time, we can not let the third party know what this symmetric encryption algorithm, what to do?

Using random numbers is the use of random numbers to generate symmetric cryptographic algorithms. This allows the server and client each interaction is a new encryption algorithm, only the interaction of the one to determine the encryption algorithm.

Now, you see why there are so many random numbers in the HTTPS protocol handshake phase.

How do I get the public key?

Careful people might have noticed. If you use an asymmetric encryption algorithm, our client, a, and b need to hold the public key at the outset, or they cannot perform cryptographic behavior.

Now, we have a new problem, how to get a, B clients to secure the public key?

The only solution I can think of is this:

Scenario 1. Server-side sends the public key to each client

Scenario 2. The server side puts the public key on a remote server that the client can request to get

We chose Scenario 1 because scenario 2 had one more request and another to handle the placement of the public key.

What if the public key is switched? Another chicken with eggs, a chicken problem?

However, Scenario 1 has a problem: What if the server sends the public key to the client and is switched by the middleman?

I drew a picture to make it easy to understand:

Obviously, it is unrealistic for each client browser to save the public key of all the sites by default.

Use the public key of a third-party organization to solve the problem of chicken laying eggs and raw chickens

The problem with the public key being switched is because our clients cannot tell whether the person returning the public key is an intermediary or a real server. This is actually the authentication problem mentioned in cryptography.

If you were to solve it, how would you solve it? If you know about HTTPS, you will know to use a digital certificate to resolve it. But have you ever thought about the nature of the certificate? Please put down your knowledge of https and try to find a solution yourself.

That's how I solve it. Since the server needs to pass the public key to the client, the process itself is unsafe, so why not encrypt the process itself again? However, are you using symmetric encryption or asymmetric encryption? Well, I feel like I'm in the chicken with the eggs and the chickens.

The problem is that if we choose to pass the public key directly to the client, we will never be able to solve the problem of the transfer of the public key by the middleman.

Therefore, we cannot pass the public key of the server directly to the client, but the third party uses its private key to encrypt our public key and then pass it on to the client. The client then decrypts using the public key of the third-party organization.

is the first version of the "digital certificate" We designed, the certificate only the server to the third party's public key, and this public key is encrypted by the private key of the third party organization:

If it can be decrypted, it means that the public key is not swapped by the middleman. Because if a middleman uses his own private key to encrypt something to the client, the client cannot decrypt it with a third-party public key.

I thought it was a problem to solve. But the reality of HTTPS, there is a concept of digital signature, I can not understand its design reasons.

Originally, I missed a scene: third-party organizations can not only give you a company to produce a certificate, it may also give the intermediary such a bad idea of the company issued a certificate. In this way, the intermediary will have the opportunity to swap your certificate, the client in this case is not able to tell whether to receive your certificate, or the middleman. Because both the middleman and your certificate can be decrypted using the public key of the third-party organization. Like this:

Where a third-party agency issues certificates to multiple companies:

The client can decrypt all certificates issued by the same third institution:

Eventually lead to other intermediaries holding the same third-party certificate can be switched:

Digital signatures to solve the problem of tampering with different certificates issued by the same agency

To solve this problem, we must first understand a problem, to identify the role of different certificates in the same institution, where should we put it?

Can only be placed on the client. This means that after the client has received the certificate, it has the ability to tell if the certificate has been tampered with. How can we have this ability?

We look for inspiration from the real world. For example, you are the HR, you get the candidate's academic credentials, the certificate written on the holder, the authority, the issue of time, and so on, while the certificate, but also wrote the most important: Certificate number! How do we identify this certificate as TRUE or False? Just take this certificate number on the relevant agencies to check, if the certificate on the holder and the actual candidate is consistent with the certificate number can also correspond, then the certificate is true.

Can our client use this mechanism? Like this:

But where is this "third-party organization"? Is it a remote service? Isn't it possible? If it is a remote service, the entire interaction will be slow. Therefore, the verification function of this third party organization can only be placed on the client's local.

How does the client authenticate the certificate locally?

How does the client authenticate the certificate locally? The answer is that the certificate itself tells the client how to verify the authenticity of the certificate.

That is, the certificate says how to generate a certificate number based on the content of the certificate. After the client has obtained the certificate, it generates a certificate number on its own basis, if the certificate number is the same as the certificate number on the certificate, then the certificate is true.

Also, to prevent the certificate number itself from being swapped, use a third-party private key for encryption.

This place is a little abstract, let's take a diagram to help understand:

The production of certificates. The "number Generation method MD5" in the certificate tells the client that you can obtain a certificate number by using MD5 to evaluate the contents of the certificate.

When the client gets the certificate, it begins validating the contents of the certificate, and if the client calculates a certificate number that is the same as the certificate number in the certificate, the validation passes:

But how does the public key of a third-party organization run into the client's machine? So many machines in the world.

In fact, in reality, browsers and operating systems maintain a list of authoritative third-party institutions (including their public keys). Because the issuing authority is written in the certificate received by the client, the client will find the appropriate public key locally based on the value of this authority.

Off-topic: if the browser and operating system this line of defense is broken, there is no way. Think of the non-conventional XP system that you have installed, you are afraid.

Speaking of which, presumably, you already know that the certificate is a digital certificate in HTTPS, the certificate number is a digital signature, and a third-party organization means a digital certificate authority (CA).

How does the CA issue a digital certificate to the server side?

When I heard this question, I mistakenly thought that our server needs to send the network request to the CA department's server to take this certificate. Is it my ability to understand the problem, or.

In fact, the question should be how the CA was issued to our webmaster, and how our administrator put the digital certificate on our server.

How do we apply to CA? Every CA agency is the same, I found one on the Internet:

Once we get the certificate, we can configure the certificate on our own server. So how to configure? This is the specific details, left to everyone Google.

Maybe we need to sort out our ideas.

We try to restore the HTTPS design process by extrapolating. In this way, we also understand why HTTPS is so much more interactive than HTTP, why HTTPS performance is poor, and find the performance tuning point for HTTPS.

And a whole bunch of work is done to get the client and the server to negotiate a symmetric encryption algorithm safely. This is the main job of the SSL/TLS protocol in HTTPS. All that is left is the encryption and decryption of the symmetric encryption algorithm used by both parties during the communication.

Here is a real interaction diagram of the HTTPS protocol (copy from the online, forget where, if the infringement trouble to inform):

Can you summarize https in a sentence?

The answer is no, because HTTPS itself is too complex. But I'm still trying to summarize https with a few words:

HTTPS to make the client-server communication process secured, must use the symmetric encryption algorithm, but the process of negotiating symmetric encryption algorithm, the use of asymmetric encryption algorithm to ensure security, but the process of using asymmetric encryption itself is not secure, there will be the possibility of the middleman tamper with the public key, So the client and server do not use the public key directly, but instead use a certificate issued by a digital certificate authority to ensure the security of the asymmetric encryption process itself. Through these mechanisms, a symmetric encryption algorithm is negotiated, which is used by both parties to encrypt and decrypt the algorithm. This solves the communication security problem between client and server side.

A very long passage.

Translated from: http://blog.jobbole.com/110354/

HTTPS principle Popular Understanding