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

This article introduces the relevant knowledge of "Why HTTPS is safer than HTTP". In the operation of practical cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

HTTP protocol

HTTP (Hyper Text Transfer Protocol) protocol is the abbreviation of hypertext transfer protocol. It is the transport protocol of Hypertext markup language (HTML) from WEB server to local browser. It is located in the application layer of OSI network model.

HTTP is a protocol that transmits data based on TCP/IP communication protocol. The types of data transferred are HTML files, picture files, query results and so on.

The HTTP protocol is generally used in the Bamp S architecture. As a HTTP client, the browser sends all requests to the HTTP server, the WEB server, through URL.

Characteristics of HTTP

HTTP protocol supports client / server mode, which is also a request / response mode protocol.

Simple and fast: when a customer requests a service from the server, it only needs to send the request method and path. GET, HEAD and POST are commonly used in request methods.

Flexibility: HTTP allows the transfer of any type of data object. The type of transmission is marked by Content-Type.

Connectionless: limits the processing of only one request per connection. After the server processes the request and receives the reply from the client, it disconnects, but it is not conducive to the client maintaining a session connection with the server. in order to make up for this deficiency, there are two techniques for recording the status of http, one is called Cookie and the other is called Session.

Stateless: stateless means that the protocol has no memory for the transaction, and subsequent processing requires previous information and must be retransmitted.

HTTP man in the middle attack

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

We know that messages in HTTP protocol are transmitted in clear text without any encryption, which will lead to man-in-the-middle attacks.

For example: Xiao Ming JAVA post bar post, the content is I love JAVA:

Attacked by the middleman, the content was modified to I love PHP

What the server receives is the wrong message: I love PHP

In addition, the requested information can also be intercepted and impersonated by eavesdropping.

How to prevent man-in-the-middle attacks

Since HTTP is a plaintext transmission, it would be nice to encrypt it in our home.

Symmetrical encryption

Symmetric encryption is easy to understand, that is, the same key used for encryption and decryption is symmetrical. As long as the security of the key is ensured, the whole communication process can be said to be confidential.

For example, if you want to log on to a website, as long as you agree with it in advance to use a symmetric key, all the ciphertext is encrypted with the key, and only you and the website can decrypt it. Even if the hacker can eavesdrop, all he can see is garbled code, because the plaintext cannot be deciphered without a key, so confidentiality is realized.

Cons: this encryption is good, but the problem is how to let both parties know the secret key, the term "key exchange". Because the data is transmitted through the network, once the secret key is intercepted, there is no meaning to encrypt it.

Asymmetric encryption

Also known as public key encryption algorithm, it has two keys, one is called public key (public key), and the other is called private key (private key). The two keys are different and asymmetric, and the public key can be made public to anyone, while the private key must be kept strictly secret.

Public key and private key have a special one-way, although both can be used for encryption and decryption, but public key encryption can only be decrypted with private key, conversely, private key encryption can only be decrypted with public key.

Asymmetric encryption can solve the problem of key exchange. The website keeps the private key secretly and distributes the public key on the Internet at will. If you want to log on to the website, just encrypt it with the public key. The ciphertext can only be decrypted by the holder of the private key. The hacker cannot crack the ciphertext because he does not have a private key.

This encryption method can perfectly solve the problems of symmetric encryption. Assuming that symmetric encryption is now needed at both ends, you can use asymmetric encryption to exchange keys before that.

The simple process is as follows: first, the server publishes the public key, and then the client knows the public key. Next, the client creates a secret key, and then encrypts it through the public key and sends it to the server. After receiving the ciphertext, the server decrypts the correct key through the private key. Then both sides know what the secret key is.

So is it absolutely safe to do so?

In order to correspond to this encryption method, the middleman came up with a new cracking scheme. Since I couldn't get the private 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 he can get the plaintext of the user's request

In the process of man-in-the-middle-> server, the man-in-the-middle simulates the client's behavior, so that you can get the plaintext of the server's response

This time the communication was intercepted again by the middleman, who forged a pair of public and private keys and sent the public keys to the user to steal the private key generated by the client, which could be easily decrypted after getting the private key.

Still did not completely solve the problem of man-in-the-middle attack, how to do it? Let's take a look at how HTTPS solves the problem of communication security.

HTTPS

HTTPS is not a new protocol in the application layer, but is actually the abbreviation of HTTP+SSL/TLS.

The difference between HTTP and HTTPS:

HTTP is a hypertext transfer protocol, information is plaintext transmission, and HTTPS is a secure TLS (SSL) encrypted transport protocol.

HTTP and HTTPS use completely different connection methods and different ports. The former is 80 and the latter is 443.

The connection of HTTP is very simple and stateless; HTTPS protocol is a network protocol built by HTTP+SSL/TLS protocol for encrypted transmission and identity authentication, which is more secure than HTTPS protocol.

SSL/TSL

SSL is secure Sockets layer (Secure Sockets Layer), which is at layer 5 (session layer) in the OSI model. When SSL develops to v3, it is renamed to TLS (Transport layer Security, Transport Layer Security). It is formally standardized, and the version number is re-calculated from 1.0, so TLS1.0 is actually SSL v3.1.

Today, three versions of TLS have been developed: 1.1in 2006, 1.2in 2008, and 1.3in 2018. Version 1.2 is the most widely used

HTTPS transmits information through HTTP, but the message is encrypted through the TLS protocol

The TLS protocol is located above the transport layer and below the application layer. The first TLS protocol transmission requires two RTT, and then it can be reduced to one RTT via Session Resumption

Two encryption techniques are used in TLS: symmetric encryption and asymmetric encryption. Symmetric encryption is used in the encryption of content transmission, and asymmetric encryption only works in the certificate verification phase:

The server passes the public key through the SSL certificate, and the client will verify the SSL certificate, in which the certificate authentication system is the key to ensure the security of SSL. Next, we will explain the CA authentication system and see how it prevents man-in-the-middle attacks.

CA authentication system

Authoritative certification body

In the CA authentication system, all certificates are issued by the authority, and the CA certificates of the authority are already built into the operating system. We call these certificates CA root certificates.

Issue a certificate

We send the public key and site-related information generated by the server to the CA issuer, and then the relevant information sent by the CA issuer through the server is signed with the CA issuer to get the certificate of our application server. The certificate will generate the signature of the certificate content, and encrypt the signature using the private key of the CA issuer to get the certificate fingerprint. And generate a relationship chain with the superior certificate.

Here we download Baidu's certificate and have a look:

You can see that Baidu is trusted by GlobalSign G2, and the same GlobalSign G2 is trusted by GlobalSign R1. When the client (browser) verifies the certificate, it will check up level by level until the final root certificate. If there is no problem, the server certificate can be trusted.

How to verify server certificates

So how does the client (browser) verify the server certificate? first of all, it will find the superior certificate through the hierarchical relationship, decrypt the certificate fingerprint of the server through the public key in the superior certificate to get the signature (sign1), and then calculate the signature (sign2) of the server certificate through the signature algorithm. By comparing sign1 and sign2 If it is equal, it means that the certificate has not been tampered with or forged.

In this way, through the certificate authentication system, we can avoid man-in-the-middle attacks and initiate to intercept and modify the messages of HTTP communications.

Will you get caught using HTTPS?

The data of HTTPS is encrypted. Normally, the packet content captured by the packet capture tool after the request is encrypted and cannot be viewed directly.

However, as mentioned earlier, browsers will only alert you to security risks, and you can continue to visit the site and complete the request if the user is authorized. Therefore, as long as the client is our own terminal, we can set up a middleman network when we authorize it, and the packet grabbing tool is used as the agent of the middleman. Usually, the way to use the HTTPS packet capture tool is to generate a certificate, and the user needs to manually install the certificate into the client, and then all the requests initiated by the terminal interact with the packet capture tool through the certificate, and then the packet capture tool forwards the request to the server. Finally, the result returned by the server is output in the console and returned to the terminal, thus completing the closed loop of the whole request.

Since HTTPS cannot prevent packet capture, what is the point of HTTPS? HTTPS can prevent users from unknowingly monitoring communication links, and does not provide protection for packet capture operations that are actively granted credit, because users are already aware of the risks in this scenario. To prevent packets from being caught, we need to adopt application-level security protection, such as private symmetric encryption, and do a good job of anti-decompilation reinforcement on the mobile side to prevent local algorithms from being cracked.

Summary

We use HTTP man-in-the-middle attack to understand why HTTP is not secure, and then talk about the principle of HTTPS from security attack and defense, and finally talk about the issue of HTTPS packet capture, hoping to give you a deeper understanding of HTTPS.

That's all for the content of "Why HTTPS is safer than HTTP". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.