The HTTP protocol

The Hyper Text Transfer Protocol (HTTP) is short for HyperText Transfer Protocol. It is a Protocol for transmitting hypertext Markup Language (HTML) from WEB servers to local browsers. It is located at the application layer of the OSI network model

HTTP is a protocol based on TCP/IP communication protocol to transfer data, data transfer types such as HTML files, pictures, and query results.

HTTP is generally used in B/S architecture. As the HTTP client, the browser sends all requests to the HTTP server, namely the WEB server, through the URL.

HTTP features

  • HTTP supports client/server mode and is a request/response mode protocol
  • Simple and fast: when a client requests services from the server, it only needs to send the request method and path. The commonly used request methods are GET, HEAD and POST
  • Flexibility: HTTP allows the transfer of any type of data object. The Type of transport is marked by content-Type.
  • Connectionless: Limit processing to one request per connection. After the server processes the request and receives the reply from the client, it disconnects, but it is not good for the client to maintain the Session connection with the server. In order to make up for this deficiency, two technologies for recording THE HTTP state are produced, one is called Cookie and the other is called Session.
  • Stateless: Stateless means that the protocol has no memory for transaction processing. If the previous information is required for subsequent processing, it must be retransmitted.

HTTP man-in-the-middle attack

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

We know that HTTP packets are transmitted in plaintext without any encryption, which leads to man-in-the-middle attacks

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

Attacked by a middleman and modified to say I love PHP

The server receives the wrong message: I love PHP

In addition, request information is also vulnerable to interception, impersonation

How do I prevent man-in-the-middle attacks

Since HTTP is a plaintext transmission, then our home encryption is not good

Symmetric encryption

Symmetric encryption is easy to understand, that is, encryption and decryption use the same key, is symmetric. 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 in to a website, as long as you agree with it in advance to use a symmetric key, the communication process is all encrypted ciphertext, only you and the website can decrypt. Even if a hacker is able to eavesdrop, all he sees is gibberish. Without a key, the plaintext cannot be solved, thus achieving confidentiality.

Cons: This type of encryption is great, but the problem is getting both parties to know the secret key, a term called “key exchange.” Because all the data is transmitted over the network, if the secret key is transmitted over the network, once the secret key is captured, there is no sense of encryption.

Asymmetric encryption

Also known as public key encryption algorithm, it has two keys, a public key and a private key. The two keys are different and asymmetrical, and the public key can be made public for anyone to use, while the private key must be kept strictly secret.

Public and private keys have a special unidirectional property. Although both can be used for encryption and decryption, the encrypted public key can only be decrypted with the private key, and vice versa.

Asymmetric encryption can be solvedKey exchangeThe problem. The website keeps the private key in secret and distributes the public key arbitrarily on the Internet. You want to log in to the website as long as it is encrypted with the public key, and the ciphertext can only be decrypted by the private key holder. Hackers can’t crack the ciphertext because they don’t have a private key.

This encryption method can perfectly solve the problems of symmetric encryption. Assuming symmetric encryption is now required on both ends, asymmetric encryption can be used to exchange the secret keys before doing so.

The simple process is as follows: The server first discloses the public key, so that the client also knows the public key. Then the client creates a secret key, encrypts it through the public key and sends it to the server. The server receives the ciphertext and decrypts the correct secret key through the private key. At this time, both ends know what the secret key is.

So it’s perfectly safe to do this?

So-called while the priest climbs a post, the devil climbs, while the priest climbs a post, the broker in order to correspond the encryption method and came up with a new decoding scheme, since can’t get the private key, then I can simulate them as a client and the server, in the process of user – > middlemen, middlemen and simulate the behavior of the server, so that we can get the user requests cleartext, In the man-in-the-middle -> server process, the man-in-the-middle emulates the client behavior so that it can get the clear text of the server response for a man-in-the-middle attack

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

Or not completely solve the problem of man-in-the-middle attack, how to do nan? Let’s look at how HTTPS solves communication security problems.

HTTPS

HTTPS is not a new protocol at the application layer. In fact, it is short for HTTP+SSL/TLS

The difference between HTTP and HTTPS

  • HTTP is a hypertext transmission protocol, and information is transmitted in plain text. HTTPS is a SECURE TLS (SSL) encryption transmission protocol
  • HTTP and HTTPS use completely different connections and use different ports, the former 80 and the latter 443
  • HTTP connections are simple and stateless; HTTPS is a network protocol that uses HTTP+SSL/TLS to encrypt transmission and authenticate identity. It is more secure than HTTPS.

SSL/TSL

SSL (Secure Sockets Layer), which is Layer 5 in the OSI model (session Layer), was changed to TLS (Transport Layer Security) when SSL was developed in V3. The version number is recalculated from 1.0, so TLS1.0 is actually SSL v3.1.

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

HTTPS transmits information over HTTP, but the information is encrypted over the TLS protocol

The TLS protocol is located above the transport layer and below the application layer. The first TLS protocol transfer requires two RTTS, which can then be reduced to a single RTT through Session Termination

Two encryption technologies are used in TLS, namely, symmetric encryption and asymmetric encryption. Symmetric encryption is used for the encryption of content transmission, and asymmetric encryption only applies to the certificate verification phase:

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

CA Certification System

Certification authority

In the CA authentication system, all certificates are issued by the authority, and the CA certificates of the authority are built-in in the operating system. These certificates are called CA root certificates

Certificate issued by

We send the public key generated by the server and related information of the site to the CA issuing authority, and then the CA issuing authority signs the relevant information sent by the server to obtain the certificate of our application server. The certificate will be signed with the corresponding content of the generated certificate. The signature is encrypted with the private key of the CA to obtain the certificate fingerprint, and the relationship chain is generated with the upper-level certificate.

Here we download baidu’s certificate to have a look:

As you can see, Baidu is trusted by GlobalSign G2, and GlobalSign G2 is trusted by GlobalSign R1. When the client (browser) does certificate verification, it checks the certificate level by level up until the final root certificate. If there is no problem, the server certificate can be trusted.

How do I verify the server certificate

So the client (browser) is how to verify the server certificate, first through the hierarchy to find the superior certificate, through the superior certificate public key to decrypt the server certificate fingerprint signature (SIGN1), and then through the signature algorithm to calculate the signature of the server certificate (SIGN2), By comparing SIGN1 and SIGN2, if they are equal, the certificate is neither tampered nor forged.

In this way, through the certificate authentication system, we can avoid the man-in-the-middle attack and initiate interception and modification of HTTP communication packets.

Can PACKETS be captured using HTTPS?

HTTPS data is encrypted. Generally, packets captured by the packet capture tool are in the encrypted state and cannot be viewed.

However, as mentioned above, the browser will only alert you to security risks if the user is authorized to continue accessing the site and complete the request. Therefore, as long as the client is our own terminal, we can set up the middleman network under the condition of authorization, and the packet capture tool is the agent acting as the middleman. The use of the HTTPS caught tool is usually generates a certificate, the user needs to manually install the certificate to the client, then the terminal by all the request through the certificate completed and caught tools of interaction, and then caught tools forward requests to the server, finally, the server returns the results in the console output and then returned to the terminal, Thus completing the loop of the entire request.

If HTTPS can’t prevent packet capture, what’s the point of HTTPS? HTTPS prevents communication links from being monitored without users’ knowledge. However, HTTPS does not provide protection against packet capture with active credit, because users are already aware of risks in this scenario. To prevent packet capture, application-level security protection is required, such as proprietary symmetric encryption, and anti-decompilation hardening on mobile terminals to prevent local algorithms from being cracked.

conclusion

We understand why HTTP is insecure by HTTP man-in-the-middle attack, and then from the security attack and defense technology evolution to the principle of HTTPS, finally talk about HTTPS packet capture, hoping to let you have a deeper understanding of HTTPS.

Reference:

  • Geek Time: Perspective HTTP protocol

  • Interviewer: Why is HTTPS secure

Three minutes a day