From HTTP to HTTPS, it turns out to be so simple

[[354426]]

【51CTO.com original article】

HTTP Begin

1. What is HTTP

HTTP is a text-based transmission protocol located in the application layer of the OSI seven-layer model. HTTP communicates by sending requests from the client to the server and the server responds to the request. Up to now, the HTTP protocol consists of 6 independent protocol descriptions, namely RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234 and RFC 7235.

When talking about HTTP, we have to talk about communication messages. Let's take a look at HTTP communication messages. Communication messages are divided into request messages and response messages.

① Request message

HTTP request messages usually consist of four parts: request line, request header, blank line, and request data, as shown in the following figure:

The request line consists of three fields: request method, URL and HTTP protocol version. It should be noted here that the request method can be GET, POST, HEAD, PUT, DELETE, OPTIONS, TRACE, CONNECT, but the most commonly used ones are GET, POST, DELETE and PUT.

The request header consists of a large number of key-value pairs. The data in the request header tells the server about the client. Common request headers include User-Agent browser type, Accept list of content types that the client can recognize, and Host host name of the request. Next is a blank line, which is mainly used to inform the server that the current line is no longer a request header.

Request data is mainly used in the POST and PUT methods to submit client form information to the server, and generally needs to be used in conjunction with Content-Type and Content-Length.

②Response message

The response message also consists of three parts: status line, message header and response body. The status line is used to inform the client of the requested resource. The status line consists of the HTTP version, the server response status code and the status code text description. Here we need to talk about the response status code. The status code types are shown in the following table:

The above table shows a lot of response status codes, but most of them are rarely encountered in actual use. There are 7 status codes that are often encountered, as shown in the following table:

2. HTTP’s fatal flaw

HTTP has a fatal flaw, which is that HTTP messages are transmitted in plain text, which can lead to man-in-the-middle attacks. What is a man-in-the-middle attack? Let's talk about it in the form of pictures and text.

A sent a sentence "I am fine today" from the client to the server. At this time, it was intercepted by B before the data reached the server. B changed the content to "I was fine yesterday" and sent it to the server. Finally, the information received by the server was "I was fine yesterday" instead of "I am fine today".

Here B is the middleman, and all operations performed by B are called man-in-the-middle attacks. A picture is worth a thousand words. Let's take a look at the picture.

3. HTTP means of preventing fatal flaws

In order to prevent man-in-the-middle attacks, we need to encrypt the message information we send. Generally speaking, we use two encryption methods to prevent man-in-the-middle attacks: symmetric encryption and asymmetric encryption.

①Symmetric encryption

First, A sends a message to tell the server that I want to communicate with you. After receiving this message, the server responds with a message to tell A the encryption method (such as AES encryption) and key. Finally, A encrypts the message using the encryption method agreed with the server and sends it. After receiving the message, the server can decrypt it using the key.

Can you see anything from the picture above? Although the content sent has been encrypted, the encryption method and key are still in plain text. If the middleman intercepts the first communication, he can use the intercepted encryption method and key to decrypt the subsequent communications, modify the content, and then encrypt it with the same encryption method and key before sending it to the server.

②Asymmetric encryption

For the above situation, we can use asymmetric encryption to encrypt the key. Similarly, A sends a message to the server to tell it that it wants to communicate with you. After receiving the message, the server first uses asymmetric encryption (such as RSA) to generate a public key and a private key. Then the server sends the public key to A. A generates a key locally and encrypts it with the public key sent back by the server. After completion, it sends it to the server. After receiving it, the server uses the private key to decrypt it to obtain the symmetrically encrypted key. Finally, both parties communicate using the agreed encryption method and key.

So far so good, the keys and information are encrypted, so everything should be fine. Is this really the case? If so, there is no need for HTTPS.

Since the keys are encrypted, the middleman can obtain the encryption method and public key sent by the server to the client when intercepting the first communication, and then generate a private key and a public key for himself, and replace the public key sent by the intercepted server with the public key generated by himself and send it to the client. At this time, the public key of the client to encrypt the AES key belongs to the middleman.

The client encrypts the AES key and sends it to the server. The middleman intercepts it again and uses his private key to parse the ciphertext to get the AES key. Then he uses the server's public key to encrypt the AES key and sends it to the server. Finally, during the entire communication between the client and the server, the middleman can use the received AES key to decrypt and modify the information.

At this point, some students will definitely ask, these two methods cannot completely avoid man-in-the-middle attacks, are there any other ways? Now our great HTTPS is about to come on stage, which can completely avoid man-in-the-middle attacks.

HTTPS End

1. What is HTTPS

HTTPS is the abbreviation of HTTP and TLS. The previous HTTPS used SSL, and the current HTTPS uses SSL. TLS is generally the same as asymmetric encryption, mainly for AES key encryption.

In simple terms, A sends a message to the server to tell the server that I want to communicate with you, and then the server returns a TLS/SSL certificate. After receiving the certificate, the client verifies the validity of the certificate. If the certificate is valid, it generates an AES key and encrypts it with the public key in the certificate, and then sends it to the server. After the server confirms receipt, it can use the AES key for encrypted communication.

2. About CA Certification System

The CA authentication system is the core of HTTPS to prevent man-in-the-middle attacks. The client needs to verify the security of the certificate sent by the server. So how does the client verify the security of the certificate? Let's explain it below.

Certificates are issued by authoritative certification bodies, and the certificates issued by these certification bodies have been built into the operating system (this is the case with Windows, but I don’t know about other operating systems). These certificates are called CA root certificates.

When our server needs to use HTTPS, it is necessary to send the public key generated by the server and the website-related information to the authoritative certification body. The authoritative certification body then signs the relevant information sent by the server to obtain the server certificate. The signature of the certificate content corresponding to this certificate is generated, and the signature is encrypted with the private key of the authoritative certification body to obtain the certificate fingerprint, and a relationship chain is generated with the superior certificate (the superior certificate is ultimately the CA root certificate).

When the client receives the certificate sent by the server, it will first find the superior certificate through the hierarchical relationship, and then use the public key in the superior certificate to decrypt the certificate fingerprint of the server certificate and obtain the signature after decryption.

Then the signature of the server certificate is calculated through the signature algorithm, and the two signatures are compared to see if they are the same. If they are the same, it means that there is no problem with the certificate sent by the server.

The RSA used for certificate verification here cleverly verifies the validity of the certificate by encrypting the certificate signature with a private key and decrypting it with a public key. The CA certification system can prevent the middleman from stealing the AES key and initiating interception and modification of HTTP communication messages.

Conclusion

This article talks a lot about HTTP and HTTPS. It seems very basic, but in fact, in many cases, the inaccurate data we send or receive is caused by man-in-the-middle attacks. Therefore, we should use HTTPS as much as possible when developing and deploying websites.

Author: Zhu Gang, pen name Uncle Meow

Introduction: Senior .NET developer, one of the top 20 bloggers in 2019, has been engaged in the design and development of e-government systems and AI customer service systems for a long time, and is currently working in a domestic BIM company engaged in the development of bidding software.

Editor: Tao Jialong

Call for papers: Technical people who wish to submit papers or seek coverage please send a private message to the editor

[51CTO original article, please indicate the original author and source as 51CTO.com when reprinting on partner sites]