As more and more Internet business is switched to the encrypted HTTPS from the plaintext HTTP, distributed denial of service (DDoS) attacks against HTTPS are also on the rise, including attacks targeting the SSL/TLS handshake and HTTPS services. Protecting against HTTPS-targeted DDoS attacks has always been a hard nut to crack within the industry. This document describes the working principle and harm of this kind of attacks as well as the protection design and practices.
1. Introduction
A Distributed Denial-of-Service attack DDoS an attack meant to paralyze the target service or make the target be disappeared from the Internet. Arguably, this kind of attack is one of the most powerful and the most difficult attacks to defend against. As a common attack targeting the network layer and the application layer, the persistent research on DDoS attack and analysis technologies on protocols and packets have brought about mature anti-DDoS solutions.
As customers raise higher security requirements and some policies prescribe mandatory security requirements (for example, Apple requires HTTPS connections for AppleStore), more and more network services, proactively or passively, have been switched to HTTPS from HTTP. HTTPS transmits encrypted packets on the network, rendering the traditional content detection technology useless. As handling HTTPS connections is resource consuming, it is possible for attackers to launch devastating DDoS attacks targeting HTTPS at a low cost.
This document describes the working principle of HTTPS-targeting DDoS attacks to show the uniqueness of such attacks, as well as presents the common protection approach and practices concerning targeted protection.
2. Working Principle of HTTPS-Targeting DDoS Attacks
2.1 Introduction to HTTPS
The traditional HTTP transmits packets in plaintext and is susceptible to interception and defacement. SSL/TLS provides the identity authentication and information confidentiality and integrity check functions. Built upon HTTP, HTTPS implements SSL/TLS-encrypted information exchange using three common protocols, i.e., TCP, SSL/TLS, and HTTP.
Figure 2.1 HTTPS protocol
HTTPS-targeting DDoS attacks are mainly launched against TCP, SSL/TLS, and HTTP. This chapter describes how DDoS attacks target the three protocols.
2.2. TCP-Targeting Attacks
This kind of common attacks mainly refers to attacks such as SYN flood and ACK flood launched against HTTPS servers in a bid to consume server resources like TCP connections. Such attacks do not target HTTPS-specific protocols and all servers using TCP are likely to receive these attacks.
2.3. SSL/TCP-Targeting Attacks
The SSL/TLS handshake involves asymmetric encryption algorithms, symmetric encryption algorithms, and hash algorithms. Asymmetric encryption algorithms consume a lot of calculation resources. For most asymmetric encryption algorithms, the server does far more calculations than the client in the actual situation. Here, the Rivest–Shamir–Adleman (RSA) algorithm, the most commonly used asymmetric encryption algorithm, is used as an example to describe how this kind of algorithm works.
| 1. Select a pair of prime numbers that have a similar number of bits and are large enough. 2. Calculate n=p*q. 3. Calculate φ(n)=(p−1)(q−1). 4. Select a number e (1<e<φ(n) ) that is relatively prime to φ(n). 5. Calculate d and ensure the equation: d*e≡1modφ(n). 6. The public key is (n, e) and the private key is (n, d). 7. Encrypt the message m: c=m^e mod n. Decrypt this message: m=c^d mod n. |
The following shows SSL/TLS uses the RSA algorithm for key exchange:
The client encrypts the random number m, calculates c (c=m^e mod n), and sends c to the server. Then, the server decrypts the random number m by calculating the equation m=c^d mod n. If there is not much difference between e and d, the server and the client do the similar amount of calculations. However, e and d differ greatly in the actual situation. The reason is that e is a fixed small prime number and 65537(0x10001) is commonly used as e, while d that is calculated based on e is a great value, as demonstrated in the certificate (modulus indicates n; publicExponent indicates e; privateExponent indicates d) generated based on RSA2018.
Figure 2.2 Parameters of public and private keys of the RSA certificate
In step 7 in the RSA algorithm, the server consumes much more resources than the client in the decryption process. This is due to two reasons:
1. For the historical reason, e cannot be set to a too great value (cannot exceed 32).
2. For the sake of security, d cannot be a too small value and generally should be almost as big as n[1].
Certain RSA algorithms have significantly reduced the consumption[2] of CPU resources used by the server to calculate m. However, during the actual testing, when RSA2048 is used as an SSL/TLS key exchange algorithm during the actual testing, the server consumes as much as five times more CPU resources than the client.
Given the asymmetry in resource consumption by the server and the client during the handshake, the attacker can take down the server at a lower cost by keeping establishing SSL/TLS handshakes with the server or initiating key renegotiations (such as the renowned THC-SSL-DOS). What’s worse, a client, by preparing a c’ instead of calculating a c, can cause the server to find that this SSL/TLS communication fails only after doing a huge amount of useless but costly calculations. In this way, just a few attackers can cause the server to deny service to legitimate users, appearing unresponsive to them.
2.4. HTTP-Targeting Attacks
HTTP-targeting attacks can be carried in either of the following ways:
1. Sending a large number of HTTP-encrypted packets or HTTP-encrypted spam packets prepared in advance to deplete the server’s asymmetric encryption performance.
2. The attacker causes the server to handle enormous HTTP connections or consume the server’s other additional resources, like the database.
3. HTTPS-Targeting DDoS Protection Approach
3.1 HTTPS Protection Overview
In Chapter 2, we described DDoS attacks against HTTPS mainly target TCP, SSL/TLS, and HTTPS. In this chapter, we will discuss protection against DDoS attacks based on the three protocols. In addition, HTTPS protection is a systematic engineering, involving SSL certificate management.
3.2 Protection for TCP-Targeting Attacks
Through years of accumulation of experience in DDoS protection, the security industry has provided a rich set of algorithms to defend against TCP-targeting DDoS attacks. To fight against this kind of attacks, NSFOCUS Anti-DDoS products boasts proprietary reverse detection algorithms to accurately identify bogus sources without disrupting connections for intended traffic. For the protection against attacks launched by botnets, such products can sanitize traffic by limiting the traffic rate of source IP addresses or based on NSFOCUS threat intelligence.
3.3 Protection for SSL/TLS-Targeting Attacks
Generally, SSL/TLS-targeting attacks are launched from sources that are real clients having bypassed TCP protection. Currently, there is no good way to beat computation-type attacks based on SSL/TLS. DDoS protection devices can identify abnormal clients by checking the number of key exchanges initiated by the client. This method works for TCH-SSL-DOS.
3.4 Protection for HTTP-Targeting Attacks
For HTTP-targeting protection, common algorithms are available within the security industry, including 302 redirect, JavaScript authentication, and image verification, to distinguish between legitimate users and bot programs. However, these algorithms can work on the premise that the plaintext HTTP information is obtained from decryption. Besides, protective devices need to track each HTTPS connection to the client. Evidently, protecting against such attacks finally comes down to SSL/TLS performance.
3.5 Issues in Common HTTPS Protection
Protection for DDoS attacks against SSL/TLS and higher-level protocols used by HTTPS is generally proxy protection. For example, CDN vendors scrub off attack traffic by deploying a huge cluster of devices. The target HTTPS server provides the certificate and private key to the DDoS protection proxy. Instead of accessing the server, the client communicates with the protection proxy which interacts with the server (using HTTPS or HTTP). In this case, communications between the client and the server are plaintext for the protective proxy so that the proxy can make an analysis of packet contents for further protection. This protection approach has the following issues:
- The user needs to provide the certificate and private key used by his or her own server to the protective proxy.
- Communications between the client and the server are plaintext for the protective proxy, rendering the confidentiality principle useless.
3.6 Optimized HTTPS Protection
This section introduces optimized HTTPS protection from the perspective of HTTPS’s business logic. NSFOCUS Anti-DDoS System (ADS), acting as a proxy, handles the TCP and SSL/TLS handshakes initiated by the client and authenticates the client by using a rich set of HTTP authentication algorithms. During HTTPS interactions, clients that are successfully authenticated by these algorithms are considered legitimate and subsequent packets from them will be passed through without going through any further checks.
HTTPS servers provide application-layer services. In the service process, SSL/TLS connections are only an intermediate step performed prior to HTTP business access. In addition to setting up SSL/TLS connections, legitimate users have to perform subsequent HTTP-encrypted packet exchanges. If clients fail to pass through HTTP algorithm authentication after making several SSL/TLS connection attempts, their subsequent packets will be discarded or they will be added to the blacklist. Through the holistic analysis of HTTPS interactions, we can effectively block attackers.
The authentication process is as follows: The user first imports the SSL certificate and private key of the target HTTPS server to ADS. When an HTTPS attack occurs, ADS intercepts the client’s HTTPS connection and checks the authenticity of the client using the SSL and HTTP authentication algorithms. For authenticated clients, ADS allows their communications to the server to directly pass through.
As for protection for HTTPS-targeted DDoS attacks, ADS has the following advantages over a full proxy:
- ADS can decrypt HTTPS packets and defend against HTTPS attacks using a rich set of HTTP algorithms.
- The user can import a certificate to prevent the browser from reporting an alert. For this purpose, the user can import a certificate (such as a domain validated certificate) different from the one on the server to prevent violations of legal policies.
- ADS can just check the authenticity of the client, instead of decrypting and cleaning traffic.
3.7 Protection Approach
Considering the difference between the client and the server in HTTPS connection calculations, to curb attack attempts, we can increase the client’s calculation consumption to make it impossible for attackers to initiate a great number of access requests during the unit time. The Client Puzzle[3] (CPP) protocol is a good reference: The server sends a mathematical problem to the client and does not allow the client to perform the further operation until a reply is received from the client. In this case, the client will input a lot of CPU resources to solve this mathematical problem.
4. Conclusion
HTTPS protection is a hard nut to crack in the cybersecurity industry. In this document, we introduced HTTPS-targeting DDoS attack scenarios and difficulties in protection, present common protection approaches, and set forth the HTTPS attack protection approach and practice of NSFOCUS’s ADS team.
5. References
[1] HTTPS://en.wikipedia.org/wiki/Wiener%27s_attack
[2] HTTP://www.di-mgt.com.au/crt_rsa.html
[3] HTTPS://en.wikipedia.org/wiki/Client_Puzzle_Protocol
