Why HTTPS is secure

1. HTTP protocol

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

1.1 HTTP protocol introduction

The HTTP protocol is a text-based transport protocol located at the application layer of the OSI network model.

The HTTP protocol communicates through request responses from 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:

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

The HTTP protocol is indeed very convenient to use, but it has a fatal shortcoming: it is not secure.

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

Xiao Ming posted on the JAVA forum, the content is I love JAVA:

Attacked by a man-in-the-middle, the content was modified to “I love PHP”

Xiao Ming was laughed at by the crowd (manual dog head)

It can be seen that during the HTTP transmission process, the middleman can see and modify all request and response contents in the HTTP communication, so using HTTP is very unsafe.

1.3 Prevent man-in-the-middle attacks

At this time, someone may have thought that since the content is plain text, I should use symmetric encryption to encrypt the message so that the middleman cannot see the plain text, so I modified it as follows:

The encryption method agreed upon by both parties

Encrypt messages using AES

In this way, it seems that the middleman cannot obtain the plaintext information, but in fact, the encryption method and secret key will still 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 will still Subsequent communications can be decrypted:

So in this case, we will definitely consider whether we can encrypt the secret key so that the middleman cannot see it? The answer is yes, using asymmetric encryption, we can achieve it through the RSA algorithm.

When agreeing on the encryption method, the server generates a pair of public and private keys, and the server returns the public key to the client. The client locally generates a string of secret keys (AES_KEY) for symmetric encryption, and encrypts the public key sent by the server to obtain ( AES_KEY_SECRET), and then returns it to the server. The server decrypts the AES_KEY_SECRET sent by the client through the private key to obtain AEK_KEY. Finally, the client and the server communicate encrypted messages through AEK_KEY. The transformation is as follows:

It can be seen that in this case, the middleman cannot steal the secret key used for AES encryption, so subsequent communications will definitely not be decrypted. So is this absolutely safe?

As the saying goes, the devil is as good as the devil. In order to cope with this encryption method, the middleman came up with a new cracking solution. Since I can’t get AES_KEY, I simulated myself as a combination of client and server. In the process of user -> middleman, the middleman simulates the behavior of the server, so that the clear text of the user’s request can be obtained. In the process of middleman -> server, the middleman simulates the behavior of the client, so that the plain text of the server’s response can be obtained, so as to perform the middleman attack:

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

If the middleman does whatever he wants, is there no way to punish him? Of course there is. Next, let’s take a look at how HTTPS solves communication security problems.

2. HTTPS protocol

2.1 Introduction to HTTPS

HTTPS is actually the abbreviation of SSL + HTTP. Of course, SSL has basically been replaced by TLS now, but we will still use SSL as the abbreviation. In fact, the SSL protocol is not only applied to the HTTP protocol, but also applied to various application layer protocols. on, for example: FTP, WebSocket.

In fact, the SSL protocol is roughly the same as the asymmetric encryption in the previous section. The handshake process is mainly to exchange secret keys, and then use symmetric encryption to communicate during the communication process. The approximate process is as follows:

I just drew a schematic diagram here. In fact, the real SSL handshake will be much more complicated than this, but the nature is still similar. What we need to focus on here is how HTTPS prevents man-in-the-middle attacks.

As can be observed from the above figure, the server transmits the public key through the SSL certificate, and the client verifies the SSL certificate. The certificate authentication system is the key to ensuring SSL security. Next, we will explain the CA authentication system and take a look. How it prevents man-in-the-middle attacks.

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 authoritative organizations, and the CA certificates of authoritative organizations are already built into the operating system. We call these certificates CA root certificates:

issue certificate

If our application server wants to use SSL, it needs to issue a CA certificate through an authoritative certification agency. We send the public key and site-related information generated by the server to the CA issuing agency, and then the CA issuing agency sends the relevant information through the server. The CA issuing authority adds the signature, thereby obtaining the certificate of our application server. The certificate will generate a signature of the certificate content correspondingly, and encrypt the signature using the private key of the CA issuing authority to obtain the certificate fingerprint, and generate a relationship chain with the superior certificate. . Here we download Baidu’s certificate and take a look:

You can see that Baidu is trusted by GlobalSign G2, and GlobalSign G2 is trusted by GlobalSign R1. When the client (browser) performs certificate verification, it will check it level by level until the final root certificate. If No problem indicates that the server certificate can be trusted.

How to verify server certificate

So how does the client (browser) verify the server certificate? It first finds the superior certificate through the hierarchical relationship, uses the public key in the superior certificate to decrypt the server’s certificate fingerprint to obtain the signature (sign1), and then Calculate the signature (sign2) of the server certificate through the signature algorithm. By comparing sign1 and sign2, if they are equal, it means that the certificate has not been tampered with or forged.

What’s interesting here is that the RSA used for certificate verification cleverly verifies the validity of the certificate by encrypting the certificate signature with the private key and decrypting it with the public key.

In this way, through the certificate authentication system, we can avoid the middleman from stealing AES_KEY to intercept and modify HTTP communication messages.

Summary

-1698376938836)]

In this way, through the certificate authentication system, we can avoid the middleman from stealing AES_KEY to intercept and modify HTTP communication messages.

Summary

First, let’s understand why HTTP is insecure through HTTP man-in-the-middle attacks, and then go from the technical evolution of security attack and defense to the summary of the principles of HTTPS, hoping to give everyone a deeper understanding of HTTPS.