The disadvantage of HTTP

So far, we have learned that HTTP has a very good and convenient side. However, HTTP has not only a good side but also a bad side. Every coin has two sides. HTTP has these major shortcomings, as listed below. 1, communication using clear text (not encrypted), the content may be eavesdropped

The identity of the communication party is not verified and therefore may be disguised. 3. The integrity of the packet cannot be proved and may be tampered with. In addition, HTTP itself has many drawbacks. There are also practical limitations (also known as vulnerabilities or security holes) with specific Web servers and specific Web browsers, as well as security holes for Web applications developed in programming languages such as Java and PHP.

Communications using plaintext may be eavesdropped

TCP/IP is a network that can be eavesdropped on

If you ask why not encrypting communication is a disadvantage, it is because the TCP/IP protocol family works so that the content of communication can be accessed over all communication lines.

The so-called Internet is made up of networks that can connect to the whole world. No matter which corner of the world when the server and client communication, in this communication line on some network equipment, optical cable, computer, etc., can not be a personal private thing, so do not exclude a link will be malicious peep behavior.

Even encrypted communications can be seen, just as unencrypted communications are. It’s just that if the communication is encrypted, it might be impossible to decipher the meaning of the message, but the message itself can still be seen after the encryption.

Graph: Any corner of the Internet is at risk of eavesdropping on communications, and it is not difficult to eavesdrop on the same segment of communications. Just collect the packets (frames) that flow over the Internet. The parsing of collected packets can be handed over to PacketCapture or Sniffer tools.

Encryption prevents eavesdropping

Failure to verify the identity of the communicating party may result in a masquerade

Requests and responses in HTTP do not acknowledge the communicator. That is, there are questions like “is the server really the host specified in the URI that sent the request, and is the response actually returned to the client that actually made the request?”

Anyone can initiate a request

Find out your opponent’s credentials

Although the communication party cannot be determined using the HTTP protocol, it can be determined using SSL. SSL not only provides encryption, but also uses a device called a certificate that can be used to determine the party. The certificate is issued by a trusted third-party organization to prove that the server and client actually exist. In addition, forging certificates is technically extremely difficult. Therefore, as long as the certificate held by the communicator (server or client) can be confirmed, the true intention of the communicator can be determined.

Use certificates to prove that the communicating party is the intended server. This reduces the risk of personal information disclosure for users. In addition, the client can complete the confirmation of personal identity by holding the certificate, and can also be used for the authentication of Web sites.

Message integrity could not be proved and may have been tampered with

The content received may be incorrect

The HTTP protocol cannot prove the packet integrity of communication. Therefore, it is impossible to know whether the content of a request or response has been tampered with until the request or response is received. In other words, there is no way to confirm that the request response sent and received is the same.

For example, when downloading content from a Web site, it is impossible to determine whether the files downloaded by the client are the same as those stored on the server. The contents of the file may have been tampered with in transit. Even if the content does change, the client on the receiving end is not aware of it. Such attacks are called man-in-the-middle attacks (MITM) in which a request or response is intercepted and tampered with while in transit.

How to Prevent tampering

HTTPS to ensure Web security

HTTP+ Encryption + Authentication + Integrity Protection =HTTPS

HTTP is HTTPS with encryption, authentication, and integrity protection. If you use unencrypted plaintext during HTTP communication, such as entering a credit card number on a Web page, the credit card number is exposed if the communication line is bugged. In addition, in the case of HTTP, there is no way for the server or client to identify the communication party. It is possible that you are not actually communicating with the intended party. You also need to consider the possibility that the received message has been tampered with during communication. In order to solve these problems, encryption and authentication mechanisms need to be added to HTTP. We call HTTP with encryption and authentication mechanisms HTTPS (HTTP Secure).

HTTPS is often used for communication on the Web login page and shopping and settlement page. When using HTTPS for communication, use https:// instead of http://. In addition, when a browser visits a Web site with valid HTTPS communication, a lock symbol appears in the browser’s address bar. The display of HTTPS varies from browser to browser.

HTTPS is HTTP in an SSL shell

Public-key encryption in which keys are exchanged

Before we get into SSL, let’s look at encryption methods. SSL uses a type of encryption called public-key cryptography.

In modern encryption methods, the encryption algorithm is open, but the key is secret. In this way the encryption method can be kept secure. Encryption and decryption use keys. A password cannot be decrypted without a key; conversely, anyone with a key can decrypt it. If the key is obtained by an attacker, the encryption is meaningless.

The dilemma of shared key encryption

Public key encryption using both keys

Public key encryption solves the difficulty of shared key encryption. Public-key encryption uses a pair of asymmetric keys. One is called a private key and the other is called a public key. As the name implies, a private key cannot be known to anyone else, whereas a public key can be freely distributed and available to anyone. A public key and a private key are paired. In public-key encryption mode, the sender uses the public key of the other party to encrypt the ciphertext. After receiving the encrypted message, the other party uses its private key to decrypt the encrypted message. In this way, there is no need to send the private key for decryption, and there is no need to worry about the key being eavesdropped and stolen by an attacker. In addition, it is extremely difficult to recover the original information based on ciphertext and public keys, because the decryption process involves evaluating the discrete logarithm, which is not easy to do. At the very least, if you can factor a very large integer quickly, there is hope for password cracking. But it’s not realistic with the current technology.

HTTPS uses a hybrid encryption mechanism

A certificate certifying the correctness of a public key

Secure communication mechanism of HTTPS

To better understand HTTPS, let’s look at HTTPS communication steps.

Step 1: The Client sends a Client Hello packet to start SSL communication. The packet contains the specified VERSION of SSL supported by the client and the Cipher Suite list (encryption algorithm and key length). Step 2: When SSL communication is enabled, the Server responds with Server Hello packets. As with the client, the message contains the SSL version as well as the encryption component. The server’s encryption component content is filtered from the received client encryption component. Step 3: Then the server sends a Certificate packet. The message contains a public key certificate. Step 4: The Server sends a Server Hello Done packet to notify the client that the INITIAL SSL handshake negotiation is complete. Step 5: After the first SSL handshake, the Client responds with a Client Key Exchange packet. The packet contains a random password string called pre-master secret, which is used in communication encryption. The packet is encrypted with the public key in Step 3. Step 6: The client sends a Change Cipher Spec packet. The packet prompts the server that the communication after the packet is encrypted with the pre-master secret key. Step 7: The client sends a Finished packet. The packet contains the overall checksum of all packets so far connected. Whether the handshake negotiation can succeed depends on whether the server can decrypt the packet correctly.

Step 8: The server also sends a Change Cipher Spec packet. Step 9: The server also sends a Finished packet.

Step 10: After exchanging Finished packets between the server and client, the SSL connection is established. Of course, the communication is protected by SSL. This is where application layer protocol communication starts, that is, sending HTTP requests. Step 11: Application layer protocol communication, that is, sending HTTP responses. Step 12: Finally disconnect from the client. When the connection is disconnected, the close_notify packet is sent. After this step, a TCP FIN packet is sent to close the communication with TCP. In the preceding process, the application layer attaches a Message Authentication Code (MAC) digest to the data it sends. The MAC checks whether packets are tampered to protect packet integrity. Below is a diagram of the process. The figure illustrates the entire process of establishing HTTPS communication from using only server-side public key certificates (server certificates).

The SSL and TLS

Is SSL slow

The problem with HTTPS is that it slows down when SSL is used.

There are two types of SSL slowness. One is slow communication. On the other hand, the processing speed slows down due to the large consumption of CPU and memory resources. 1. Network load can be 2 to 100 times slower than using HTTP. In addition to TCP connections and SENDING HTTP requests and responses, SSL communication is required, which inevitably increases the overall traffic volume. 2. Another point is that SSL must be encrypted. Encryption and decryption are required on both the server and client. As a result, more hardware resources are consumed by the server and client than HTTP, resulting in increased load. There is no fundamental solution to the slow speed problem, we will use hardware like SSL accelerators to improve the problem. The hardware is dedicated to SSL communication, which can improve the computing speed of SSL several times compared with software. Use the SSL accelerator only for SSL processing to share the load.

Why not use HTTPS all the time

SPDY eliminates HTTP bottlenecks

The bottleneck of HTTP

Ajax solution

Ajax (Asynchronous JavaScript and XML) is an operation that makes efficient use of JavaScript and DOM (Document Object Model). Asynchronous communication means to achieve partial Web page replacement loading. Because it updates only a portion of the page, the amount of data transferred in the response is reduced, which is an obvious advantage over previous synchronous communication.

The core technology of Ajax is an API called XMLHttpRequest, which enables HTTP communication with the server through the invocation of the JavaScript scripting language. This allows you to make a request from a loaded Web page and update only part of the page.

Getting content from the server in real time with Ajax can result in a lot of requests. In addition, Ajax still does not solve the problems of the HTTP protocol itself.

Comet solutions

The goal of SPDY

The advent of ease of use technologies, such as Ajax and Comet, has improved HTTP to some extent, but the limitations of the HTTP protocol itself have been somewhat frustrating. In order to make fundamental improvements, there need to be some protocol level changes. The SPDY protocol, which is in continuous development, is designed to eliminate HTTP bottlenecks at the protocol level.

Design and function of SPDY

Multiplexed stream

Multiple HTTP requests can be processed without limit over a single TCP connection. All requests are processed on a single TCP connection, so TCP processing is more efficient.

Prioritize requests

Compressing HTTP headers

Compressing HTTP request and response headers. As a result, fewer packets are generated and fewer bytes are sent.

Push function

Server prompt function

The server can actively prompt the client to request the required resources. Because the existence of a resource is known before the client discovers it, unnecessary requests can be avoided, for example, if the resource is cached.

Does SPDY eliminate the W EB bottleneck

WebSocket that uses the browser for full-duplex communication

Using Ajax and Comet technologies to communicate can speed up Web browsing. However, the problem is that if HTTP protocol is used for communication, it cannot completely solve the bottleneck problem. WebSocket network technology is a new protocol and API to solve these problems. At the time, WebSocket was planned as part of the HTML5 standard, but now it is becoming a separate protocol standard. The WebSocket protocol was standardized by RFC 6455 – The WebSocketProtocol on December 11, 2011.

W ebSocket design and function

W ebSocket agreement

** Once the WebSocket protocol communication connection is established between the Web server and the client, all subsequent communication relies on this proprietary protocol. ** Data in any format, such as JSON, XML, HTML or pictures, can be sent to each other during communication. Because it is a protocol based on HTTP, the initiator of the connection is still the client. Once the WebSocket communication connection is established, either the server or the client can directly send packets to the other party. Let’s list the main features of the WebSocket protocol.

Push function

Reduced traffic

As long as a WebSocket connection is established, you want it to stay connected. Not only is the total overhead per connection reduced compared to HTTP, but there is also less traffic due to the small size of the WebSocket header.

To implement WebSocket communication, after an HTTP connection is established, you need to complete a “Handshaking” step.

After a successful handshake establishes a WebSocket connection, communication uses websocket-independent data frames instead of HTTP data frames.

The long-awaited HTTP/2.0

The characteristics of the HTTP / 2.0

The goal of HTTP/2.0 is to improve the user experience of speed when using the Web. Since TCP connections are generally made through HTTP/1.1 first, let’s take a look at how they are implemented based on the following protocols. SPDY HTTP Speed + Mobility network-friendly HTTP Upgrade HTTP Speed + Mobility is a standard developed by Microsoft to improve the communication Speed and performance of mobile terminals. It is based on SPDY and WebSocket proposed by Google. Network-friendly HTTP Upgrade is a standard for improving HTTP performance in mobile communication.

HTTP/2.0 7 technologies and discussion

Web attack techniques

Most attacks on the Internet target Web sites. This chapter explains how you can attack a Web site and what the impact is. The simple HTTP protocol itself does not have security problems, so the protocol itself is hardly the target of attack. HTTP servers, clients, and Web applications running on servers are the targets of attacks. At present, most attacks from the Internet are directed at Web sites, and most of them target Web applications. This chapter describes the attack technologies for Web applications.

HTTP does not have the necessary security features

The request can be tampered with on the client side

In Web applications, the entire content of HTTP requests received from the browser can be freely changed and tampered with on the client side. So a Web application might receive something different than the expected data.

You can launch attacks against Web applications by loading attack codes into HTTP request packets. Through THE URL query fields or forms, HTTP headers, cookies and other ways to enter the attack code, if there is a security vulnerability in the Web application at this time, the internal information will be stolen, or the attacker to get management rights.



There are two attack modes against Web applications.Take the initiative to attackandPassive aggression.

An active attack that targets the server

Passive attacks that target the server

Passive attack refers to an attack mode that uses trap strategies to execute the attack code. In the passive attack, the attacker does not attack the access of the target Web application directly.

Passive attack The following describes the common attack modes.

Step 1: The attacker induces the user to trigger a trap that triggers the sending of an HTTP request with embedded attack code.

Step 2: The user’s browser or email client triggers the trap when the user is unwittingly caught.

Step 3: After being tricked, the user’s browser sends the HTTP request containing the attack code to the Web application as the target to run the attack code.

Step 4: After the attack code is executed, the Web application with security vulnerabilities becomes a springboard for attackers, which may lead to the theft of personal information such as cookies and the abuse of user rights in the login state.

The representative attacks in passive attack mode are cross-site scripting and cross-site request forgery.





Attack enterprise internal network by using user identity

Using passive attack, you can launch attacks on enterprise networks that cannot be accessed directly from the Internet. Once a user steps into the trap set by the attacker, even the Intranet of the enterprise can be attacked within the network that the user can access.

Many enterprise intranets can still be connected to the Internet to access Web sites or receive emails from the Internet. This may give the attacker a chance to induce users to trigger traps to launch attacks on the enterprise Intranet.



The following describes the common attack modes

Cross-site scripting attacks

HTTP header injection attack

HTTP Header Injection attack is an attack in which the attacker adds any response Header or body by inserting a newline into the response Header field. Passive attack mode. An attack that adds content to a header body is called an HTTP Response SplittingAttack. HTTP header injection attacks have the potential to have the following effects. Set any Cookie information to be redirected to any URL to display any subject (HTTP response truncation attack)

SQL injection attack

OS command injection attack

OS Command Injection attack means that an illegitimate operating system Command is executed to attack a Web application. Wherever Shell functions can be called there is a risk of attack. Operating system commands can be invoked from a Web application through a Shell. If the Shell is inadvertently called, an illegal OS command inserted can be executed. OS command injection attacks can send commands to the Shell to get the Windows or Linux command line to start a program. That is, OS injection attacks can execute various programs installed on the OS.

Incorrect error message handling

Open redirection

Open Redirect is a function that allows you to Redirect any specified URL. The security vulnerability associated with this feature is that if a specified redirect URL is directed to a malicious Web site, the user will be directed to that Web site. Open redirection Attack Cases The following URL redirection is used as an example to explain open redirection attack cases. This function redirects the ORIGINAL URL after specifying parameters to the URL. Example.com/?redirect=h… The attacker overwrites the parameters specified by the redirect to the corresponding connection for the booby-trapped Web site, as shown below. Example.com/?redirect=h… When the user sees the URL and thinks he is accessing example.com, he is actually redirected to hackr.jp, the specified redirect target. A reliable Web site with redirection enabled is likely to be selected by attackers and used as a springboard for phishing attacks.