Why HTTPS is secure

Source: r6a.cn/efZ2

1. HTTP protocol

Before talking about the HTTPS protocol, let's review the concept of the HTTP protocol.

1.1 Introduction to HTTP protocol

The HTTP protocol is a text-based transmission protocol, which is located in the OSI network model 应用层.

The HTTP protocol communicates through the request and response of the client and the server. The current protocol is split from the previous RFC 2616 into six separate protocol descriptions (RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) , The communication message is as follows:

request

POST http://www.baidu.com HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Content-Length: 7
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

wd=HTTP

response

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Thu, 14 Feb 2019 07:23:49 GMT
Transfer-Encoding: chunked

<html>...</html>

1.2 HTTP man-in-the-middle attack

HTTP protocol is indeed very easy to use, but it has a fatal flaw: 不安全.

We know that the messages in the HTTP protocol are transmitted in plain text without any encryption. What problems will this cause? Here is an example:

Xiao Ming posts in JAVA Post Bar, the content is 我爱JAVA:
Attacked by a man in the middle, the content is modified to我爱PHP
Xiao Ming was mocked by the group (manual dog head)

It can be seen that in the HTTP transmission process, the middleman can see and modify all the request and response content in the HTTP communication, so it is very insecure to use HTTP.

1.3 Prevent man-in-the-middle attacks

At this time, some people may have thought, since the content is plaintext, I use 对称加密the method to encrypt the message so that the middleman can't see the plaintext, so I modified it as follows:

The two parties agree on the encryption method
Use AES to encrypt messages

It seems that the middleman cannot obtain the plaintext information, but in fact, the encryption method and secret key will be exposed in plaintext during the communication process. If the first communication is intercepted, the secret key will be leaked to the middleman, and the middleman still The subsequent communication can be decrypted:

So in this case, we will definitely consider whether we can encrypt the secret key to prevent the middleman from seeing it? The answer is yes 非对称加密, we can use the RSA algorithm to achieve it.

When the encryption method is agreed upon 公私钥, the server generates a pair , the server will 公钥return it to the client, and the client locally generates a string of secret keys ( AES_KEY) for use 对称加密, and 公钥encrypts it through the server sent ( AES_KEY_SECRET), and then returns it to the server. The client is obtained by decrypting what 私钥is sent by the client , and finally the client and the server are encrypted and communicated with the message, and the transformation is as follows:AES_KEY_SECRETAEK_KEYAEK_KEY

It can be seen that in this case, the intermediary cannot steal AES加密the secret key used, so the subsequent communication will definitely not be able to decrypt it, so is it absolutely safe to do so?

The so-called Dao is one foot high and the magic is high. The middleman came up with a new cracking scheme in order to correspond to this encryption method. Since AES_KEYI ca n't get it, I will simulate myself as a combination of client and server 用户->中间人. In the process, the man in the middle simulates the behavior of the server, so that the plaintext requested by the user can be obtained, and in 中间人->服务器the process, the man in the middle simulates the behavior of the client, so that the plaintext of the server response can be obtained to perform a man-in-the-middle attack:

This time the communication was intercepted by the middleman again, and the middleman himself forged a pair of public and private keys and sent the public key to the user to steal the generated by the client AES_KEY. After getting it AES_KEY, it can easily decrypt it.

If the middleman does whatever he wants, there is no way to sanction it. Of course there is. Next, let's look at how HTTPS solves the communication security problem.

2. HTTPS protocol

2.1 Introduction to HTTPS

HTTPS is actually SSL+HTTPthe abbreviation. Of course, it has SSLbasically been TLSreplaced now. However, we will use it SSLas abbreviation. The SSLprotocol is not only applied to the HTTPprotocol, but also to various application layer protocols, such as: FTP, WebSocket.

In fact SSL, 非对称加密the nature of the protocol is roughly the same as in the previous section . The main purpose of the handshake process is to exchange secret keys, and then use it 对称加密for communication during the communication process . The approximate process is as follows:

Here I just drew a schematic diagram, in fact, the real SSL handshake will be more complicated than this, but the nature is still the same, and the focus of our attention here is how HTTPS prevents man-in-the-middle attacks.

It can be observed from the above figure that the server is passed through the SSL certificate 公钥, and the client will verify the SSL certificate. The certificate authentication system is SSLthe key to ensuring security. Next, we will explain CA 认证体系and see how it prevents man-in-the-middle attacks. of.

2.2 CA certification system

In the previous section, we saw that the client needs to verify the SSL certificate returned by the server, so how does the client verify the security of the server's SSL certificate.

Authoritative certification body
In the CA certification system, all certificates are issued by the authority, and the CA certificates of the authority are already built in the operating system. We call these certificates CA根证书:
Issue a certificate
If our application server wants to use SSL, it needs to be signed by an authoritative certification authority CA证书. We send the public key and site-related information CA签发机构generated CA签发机构by the server to the server , and then the relevant information sent through the server is used CA签发机构to sign, and we get us The certificate of the application server, the certificate will correspondingly generate the certificate content 签名, and the private key to be 签名used CA签发机构will be encrypted 证书指纹, and the relationship chain will be generated with the upper-level certificate.
Here we download Baidu's certificate to see:

It can be seen that Baidu is trusted GlobalSign G2, and the same GlobalSign G2is trusted GlobalSign R1. When the client (browser) checks the certificate, it will check level by level until the last one 根证书. If there is no problem, it 服务器证书can be trusted. .

How to verify the server certificate
So how does the client (browser) 服务器证书check it? First, it will find the upper-level certificate through the hierarchical relationship, decrypt 公钥the server through the upper-level certificate , and then calculate the server certificate through the signature algorithm . And , if they are equal, it means that the certificate is not covered or not .证书指纹签名(sign1)签名(sign2)sign1sign2篡改伪造

What's interesting here is that the RSA used for certificate verification uses the private key to encrypt the certificate signature and the public key to decrypt it to ingeniously verify the validity of the certificate.

In this way, through the certificate authentication system, we can avoid the theft by the middleman AES_KEYto initiate interception and modification of HTTP communication messages.

to sum up

First, first understand why HTTP is insecure through the HTTP man-in-the-middle attack, and then from the evolution of security attack and defense technology to the principle of HTTPS, I hope that everyone can have a deeper understanding of HTTPS.

There is no way, but the technique can be achieved; if there is no way, it ends with the technique

Welcome everyone to follow the Java Way public account

Good article, I am reading ❤️