preface

Before talking about HTTPS, IN my concept, HTTPS is more secure, requiring the server to configure a certificate, but what is HTTPS, why it is more secure, and how to achieve the whole process, I have no specific concept in mind. Therefore, I spent a few days to learn the realization of HTTPS mechanism by referring to some articles. I want to summarize what I have learned through an article, so that more students who do not know what HTTPS is have a basic understanding.

Many articles I have read are explained by a large number of words and protocol diagrams, but often make people feel a little boring. In this article, I will illustrate the evolution process from HTTP to HTTPS through a flow chart, so that you can understand some more easily. Of course, this is just the beginning. If you want to learn more about HTTPS, you still have to dive into the protocols and read some big books to achieve a complete understanding.

This article will also be synchronized to my personal website.

The body of the

What does HTTP look like?

HTTP is an application layer protocol. It is based on TCP/IP, so it just specifies some content to be transmitted, as well as header information. Then it is transmitted through TCP, and addresses by IP.

The client makes the request and the server responds. It’s as simple as that. During the whole process, there is nothing encrypted, so it is not secure, the middleman can intercept, get transmitted and respond to the data, causing data leakage.

How about a secret?

Since the data is transmitted in clear text, the simplest way we can think of to improve security is to encrypt the data before transmission, as shown below:

This type of encryption is called symmetric encryption. Encryption and decryption using the same secret key is called symmetric encryption.

Okay, we’re encrypting the data. Is the problem solved?

What about multiple clients?

This is one client, but on the WWW, there are thousands of clients. What happens?

It is obviously unreasonable to use the same secret key A for all clients. Once A user is cracked, all user information will be stolen.

Think about it, is there another way?

As you can imagine, this problem can be solved if each client is transferred with a different secret key:

How to transfer symmetric encryption key?

We apply a different symmetric encryption key to each client, so how does the client or server know this secret key? It can only generate a secret key on one side and send it to the other side via HTTP:

So how does the process of transferring the secret key guarantee encryption? If intercepted by an intermediary, the secret key is also obtained. And you might say, well, if you encrypt the secret key, how do you make sure that the process of encrypting the secret key is encrypted?

It looks like we’re walking into while(1) and we can’t get out.

Asymmetric encryption

When symmetric encryption fails, let’s change the way we think about it. There is another encryption method called asymmetric encryption, such as RSA. Asymmetric encryption has a pair of secret keys: a public key and a private key. Only the private key can unlock the contents encrypted by the public key, and all the public keys can unlock the contents encrypted by the private key (that is, the public key is paired with the secret key).

The private key is stored only on the server, and the public key can be sent to all clients.

In the process of transferring the public key, there is certainly a risk that the middleman will get the information. However, in the current situation, at least the contents encrypted by the client through the public key can be guaranteed to be unbreakable by the middleman, because the private key is only stored on the server side, and only the private key can break the contents encrypted by the public key.

Now we still have a problem. What if the public key is tampered with by an intermediary?

MITM: Man – in – the – MiddleAttack

The public key obtained by the client is false. How can I solve the problem?

Third Party authentication

The public key is swapped because the client cannot tell whether a middleman or a server is returning the public key, which is also an authentication problem in cryptography.

In HTTPS, certificates + digital signatures are used to solve this problem.

Assume that the encryption mode is MD5. After the website information is encrypted, the private key of a third-party organization is used to encrypt it again to generate a digital signature.

Digital certificate = website information + digital signature

If the middleman intercepts and replaces the server’s public key with his own public key, the existence of digital signature will cause the client verification signature mismatch, thus preventing the problem of the middleman replacing the public key.

After the browser is installed, the public keys of some authoritative third-party certification bodies, such as VeriSign, Symantec, and GlobalSign, are built-in. When verifying a signature, you can directly obtain the public keys of the relevant third-party certification bodies from the local PC and decrypt the encrypted digital signature of the private key to obtain the real signature. Then, the client generates the signature using the signature generation rule to check whether the two signatures match. If the two signatures are authenticated, the certificate fails to be obtained if they do not match.

Why is there a signature?

You can think about why there is a digital signature?

Third party certification body is an open platform, we can apply for, middleman can also apply for ah:

If you do not have a signature and only encrypt the website information with a third-party private key, there will be the following problems:

Since there is no authentication, the middleman also applies to the third-party authentication authority and then intercepts and replaces all the information with its own. The client can still decrypt the information and cannot determine whether it is the server’s or the middleman’s, resulting in data leakage.

Symmetric encryption

After safely getting the public key of the server, the client will randomly generate a symmetric secret key, encrypt it with the public key of the server, and transmit it to the server. After that, the relevant Application Data will be encrypted/decrypted with the randomly generated symmetric secret key, and the server will decrypt/encrypt it with the symmetric secret key:

Overall flow chart

HTTPS = HTTP + TLS/SSL

There are many details in HTTPS. You can use the following figure for reference:

conclusion

HTTPS is used for encryption and transmission using SSL/TLS. The client obtains the public key of the server. Then the client randomly generates a symmetric encrypted secret key, uses the public key to encrypt and decrypt all subsequent information, and completes the HTTPS process.

Welcome to follow my public number

Refer to the article

En.wikipedia.org/wiki/HTTPS www.instantssl.com/https-tutor… Tasaid.com/blog/201610… www.west.cn/faq/list.as… www.cnblogs.com/zhangshiton… www.wired.com/2016/04/hac…