Shulou(Shulou.com)06/02 Report--

Good morning, everyone. I haven't updated the article for some time.

In fact, during the epidemic, I stayed at home for more than a month and couldn't go out. I had a lot of time. I also used this time to write several new articles. However, because most of the newly written articles are in line with the contents of the new books, the new books I wrote have been delayed by the epidemic, so these articles cannot be published, and I am anxious to wait for them. I hope the epidemic will end as soon as possible and everyone can return to a normal life as soon as possible.

So let's release a technical article that has nothing to do with Android today.

The technology of https is now widely used. As Apple, Google and other major Internet leaders have forced the use of https,http in their operating systems, browsers and other mainstream products, the elimination has officially entered the countdown.

In fact, https has nothing to pay special attention to for client developers, because the code is no different from writing http requests. But it is precisely for this reason that many client developers do not know anything about https, only know that it is a secure encrypted network transmission, but have no idea how it works.

So do client developers need to know about https at all? I think it is necessary to master the working principle of https can help you to understand and solve some problems encountered in your work more effectively. In addition, there are many companies also like to ask some https-related questions during the interview, if you do not understand it at all, it is easy to be brushed off here.

I looked up a lot of online materials when I was learning https, but most of the articles are not so easy to understand, which makes many people have some fear of https. In my opinion, if you want to understand how https works, you don't have to know all the details of it (many articles on the Internet are so detailed that they are difficult to understand). In fact, you just need to master its overall work flow and figure out why it can ensure the security of network communications. Therefore, today I will bring you a https explanation that is the best to understand.

Before we officially start talking about https, we need to figure out two concepts: what is symmetric encryption and what is asymmetric encryption? These two concepts belong to the basic knowledge of cryptography and are actually very easy to understand.

Symmetric encryption is relatively simple, that is, the client and the server share the same key, which can be used to encrypt and decrypt a piece of content. The advantage of symmetric encryption is the high efficiency of encryption and decryption, but there may be some problems in security, because the key stored in the client has the risk of being stolen. The representative algorithms of symmetric encryption are: AES, DES and so on.

Asymmetric encryption, on the other hand, is more complicated, dividing keys into two types: public keys and private keys. The public key is usually stored on the client, and the private key is usually stored on the server. Data encrypted with a public key can only be decrypted with a private key, and data encrypted with a private key can only be decrypted with a public key. The advantage of asymmetric encryption is that it is more secure, because the encrypted information sent by the client to the server can only be decrypted with the server's private key, so there is no need to worry about being cracked, but the disadvantage is that the efficiency of encryption and decryption is much lower than that of symmetric encryption. The representative algorithms of asymmetric encryption are RSA, ElGamal and so on.

Once we have mastered these two concepts, we can begin to learn https. Here is a question to be asked in advance, which is also a question that you may often ask during an interview: does https use symmetric encryption or asymmetric encryption to ensure secure data transmission?

You will know the answer after learning this article.

First of all, let's take a look at the problems that exist in the traditional http mode when transmitting over the network.

Because the information is plaintext when we transmit the data, it is easy to monitor and steal the data. The schematic diagram is as follows:

In addition, the transmitted data may be tampered with by people with ulterior motives, resulting in inconsistent content between the browser and the website. The schematic diagram is as follows:

In other words, using http to transmit data has at least two risks: data monitoring and data tampering, so http is an insecure transmission protocol.

Then everyone must know that the solution is to use https, but first we try to think about how to ensure the security of http transmission, and then we can understand how https works step by step.

Since it is not secure for data to be transmitted on the network in clear text, it is obvious that we need to encrypt the data. As mentioned just now, there are two main ways of encryption, symmetric encryption and asymmetric encryption. The advantage of symmetric encryption is the high efficiency of encryption and decryption, and we are very efficient in transmitting data on the network, so it is obvious that symmetric encryption should be used here. The schematic diagram is as follows:

As you can see, because the data we transmit on the network is ciphertext, we are not afraid of being monitored to get it, because they do not know what the original text is. After receiving the ciphertext, the browser only needs to use the same key as the website to decrypt the data.

This working mechanism does seem to ensure the security of data transmission, but there is a huge loophole: how do browsers and websites agree on which keys to use?

This is definitely a difficult problem in the computer world. Browsers and websites have to use the same key to encrypt and decrypt data normally, but how to make this key known only to both of them and not to any listeners? You will find that no matter how much you agree, the first communication between the browser and the site must be plaintext. This means that according to the above workflow, we have never been able to create a secure symmetric encryption key.

Therefore, using symmetric encryption alone seems to never solve this problem, and at this time we need to introduce asymmetric encryption to help solve the problem that symmetric encryption keys cannot be securely created.

So why can asymmetric encryption solve this problem? Let's take a look at it in a schematic way:

As you can see, if we want to securely create a symmetrically encrypted key, we can let the browser generate it randomly, but the generated key cannot be transmitted directly over the network. Instead, we need to asymmetrically encrypt it with the public key provided by the website. Because the data encrypted by the public key can only be decrypted with the private key, the transmission of this data on the network is absolutely secure. On the other hand, after receiving the message, the website only needs to decrypt it with the private key to get the key generated by the browser.

In addition, in this way, asymmetric encryption is needed only when the browser and the website agree on the key for the first time, and once the website receives the key randomly generated by the browser, both sides can use symmetric encryption to communicate, so the work efficiency is very high.

So, do you think the above working mechanism is very perfect? In fact, it is not, because we are still missing a very crucial step, how can the browser get the public key of the website? Although the public key is public data, transmission on the network is not afraid of being monitored by others, but what if the public key is tampered with by others? The schematic diagram is as follows:

In other words, as long as we get the public key of any website from the network, there must be a risk that the public key will be tampered with. Once you use a fake public key to encrypt the data, it can be decrypted by others with a fake private key, and the consequences are unimaginable.

The solution design seems to have reached a dead end, because we can't safely get the public key of a website anyway, and it's obviously impossible for us to preset the public key of all the websites in the world in the operating system.

At this point, a new concept must be introduced to break the deadlock: CA institutions.

CA institutions are specially used to issue digital certificates to various websites to ensure that browsers can safely obtain the public keys of each website. So how does the CA organization accomplish this daunting task? Let's start to analyze it step by step.

First of all, as a website administrator, we need to apply to the CA organization and submit our public key to the CA organization. CA institutions will use the public key we submitted, plus a series of other information, such as the website domain name, validity period, and so on, to make the certificate.

After the certificate is made, the CA institution will encrypt it with its own private key and return the encrypted data to us. We only need to configure the encrypted data to the website server.

Then, whenever a browser requests our website, it will first return the encrypted data to the browser, and the browser will decrypt the data with the public key of the CA institution.

If the decryption is successful, we can get the certificate issued by the CA institution to our website, which of course includes the public key of our website. You can view the details of the certificate by clicking the mini-lock icon on the left side of the URL on the address bar of the browser, as shown in the following figure.

Once the public key is obtained, the next process is the same as described in the diagram.

If it cannot be decrypted successfully, it means that the encrypted data is not encrypted by a legitimate CA institution using a private key, but may have been tampered with, so a famous exception interface is displayed on the browser, as shown in the following figure.

So you might ask, is it really safe with CA? If we want to use the public key of the CA mechanism to decrypt the data on the browser side, how can we safely obtain the public key of the CA mechanism?

This problem is easy to solve, because there are unlimited websites in the world, and there are only a few CA organizations in total. Any genuine operating system will build the public keys of all the mainstream CA institutions into the operating system, so we do not need to obtain additional, decryption only need to traverse the public keys of all the built-in CA institutions in the system, as long as any one of the public keys can decrypt the data normally, it is legal.

The built-in certificates for the Windows system are as follows:

However, even if the data can be decrypted normally by using the public key of the CA mechanism, there are still problems in the current process. Because every CA institution makes certificates for thousands of websites, if an attacker knows that abc.com is using a certificate from a CA institution, he can also apply for a legitimate certificate from that CA institution, and then replace the encrypted certificate data returned when the browser requests abc.com. The schematic diagram is as follows:

As you can see, because the certificate applied for by the attacker is also made by a regular CA institution, this encrypted data can of course be decrypted successfully.

It is for this reason that all CA institutions produce certificates that contain a lot of other data in addition to the public key of the website, for example, the domain name of the website is one of the important data.

Also in the example just now, if the domain name of the website is added to the certificate, then the attacker can only return without success. Because, even if the encrypted data can be decrypted successfully, but the domain name contained in the final decrypted certificate does not match the domain name that the browser is requesting, then the browser will still display an abnormal interface. The schematic diagram is as follows:

Well, the scheme is designed here, in fact, our network transmission has been sufficiently secure. Of course, this is actually how https works.

So back to the original question: does https use symmetric encryption or asymmetric encryption? The answer is also obvious that https uses a combination of symmetric and asymmetric encryption.

Of course, if you want to dig deeper, there are plenty of details to dig into in https. But if you continue to write, this article may no longer be the best https explanation, so I think it is just right to write here.

If, like me, you are mainly engaged in client-side development, then knowing so much about https is enough to deal with common interviews and problems encountered at work.

At this point, this is the end of this article on the best-to-understand HTTPS explanation. For more related HTTPS explanations, please search the previous articles or continue to browse the relevant articles below. I hope you will support me in the future!

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.