SSL DDoS Attacks and How to Defend Against Them
SSL DDoS Attacks and How to Defend Against Them
The relevance of SSL encryption is on the rise, making online shopping and banking more secure. News portals and e-mail providers seeking to protect TCP connections from access by third parties during the processes of entering and transferring data increasingly rely on secure communication.
Use of HTTPS also pays off for companies in terms of SEO. Google has been adding ranking bonuses to websites with HTTPS encryption since 2017, favoring them above other results. Today, more than 70 % of global website traffic is HTTPS-encrypted.(1)
This is why SSL encryption is important:
- Trust / willingness to buy: verifiable compliance with modern security standards encourages customers to make purchases
- Security: sensitive and personal information (name, addresses, credit card details, login information etc.) must be encrypted as effectively as possible to ensure their secure handling
- Adherence to legal and contractual obligations: banks and insurance companies as well as online shops and portals have a legal obligation to transfer data securely
- Search engine optimization: commonly used search engines include factors like secure communication and speed in their rankings
Different types of SSL attacks
The increasing prevalence of data encryption is accompanied by a rising number of DDoS attacks on SSL-encrypted web applications. These attacks can be categorized into 3 types:
- Attacks on the network level: HTTP/SSL acts above layer 4 – everything up to and including layer 4 is not encrypted. Attacks on this level include: SYN floods, TCP garbage floods – both on SSL-enabled TCP ports
- Attacks on the SSL protocol level: the actual SSL protocol – this affects the SSL connections establishing the encrypted communication tunnels. Attacks on this level include: SSL renegotiation attacks, FREAK, Heartbleed etc.
- Attacks on the application level: The SSL-encrypted application protocol is used for the attack. Attacks on this level include: HTTP floods, brute-force attacks, WebScans etc.
Attacks of the first 2 categories require no knowledge of the encrypted contents. Looking at the TCP/IP level and the SSL protocol is enough to recognize and block this kind of attack. Visibility of the application protocol (HTTP) and the data contained therein is not required.
Only in the 3rd attack category is it necessary to have knowledge of the application protocol spoken in the SSL connection to detect a DoS attack. Taking a look at the TLS/SSL handshake is the only way to uncover an attack of that type.
Attacks on web applications with SSL encryption can be fended off by the Link11 DDoS protection solution. The following describes the working principle of the innovative cloud security technology for protection applications (also known as Link11 Web Protection).
Establishing SSL connections
SSL proxies serve as the initial termination point for SSL connections initiated by the client, so application protocol analyses can be performed on them. A 2nd secure connection is established by the relevant proxy to the final destination in the customer’s backend in order to forward requests. This ensures the required encryption.
To terminate the SSL connections, the SSL proxies need access to a valid certificate/key combination. The customer can submit certificate/key combinations to Link11 by encrypted upload. Once there, the data will be encrypted and stored securely according to the latest standards to make it impossible for third parties to gain access.
This is what an SSL-encrypted HTTP communication process via TCP looks like:
Analysis of SSL connections for DDoS defense
The termination of the SSL connections originating from the client is initiated on the Link11 proxies, which makes it possible for them to include the decrypted traffic in their analyses. The application traffic’s contents can only be made visible on the terminating proxy. The information gathered and used for analyzing the threat situation are statistical and serve to create a mathematical traffic model (called the baseline). Data is gathered in the form of indicators (number/second) including their development over time. Examples include:
- HTTP methods used (GET/POST/HEAD …)
- Distribution/relations of HTTP methods
- Distribution of URL length
- HTTP return codes
- Length of POST requests
- Number of requests in one TCP session
- Number of requests in separate TCP sessions
- Distribution of object size
- Bandwidth usage
The data is analyzed based on the client IPs making the request. The client IPs themselves are not included in the baseline. GET request tracking results in a baseline corresponding to that request type:
Based on the baselines, attacks can then be detected. Clients showing a significant deviation from the baselines are assigned “suspicious” instead of “normal” status within the internal scoring model.
Should the filter algorithms make the final determination that an attack is in progress, the addresses will show up in the Link11 web protection service’s log files alongside the criteria that were used for detection. The associated attack traffic is blocked. No further processing of IP addresses takes place on Link11’s part.
This is what an evaluation for such a log report, accessible on the Link11 web portal, looks like (attacker IP: a.b.c.d):
Encryption of frontend/backend connections
For maximum security on both channels (client-proxy, proxy-backend), Link11 offers the option to use the latest SSL/TLS versions and ciphers. Features like PFS, HSTS etc. are supported, of course.
Arising SSL/TLS vulnerabilities are analyzed immediately after they become known and suitable protection measures are taken if relevant to the Link11 web protection service.
Past examples include:
|Exploit/vulnerability||Link11 fix after publication|
|Poodle||< 1 h|
|Logjam||No vulnerability period|
|Heartbleed||No vulnerability period|
|FREAK||No vulnerability period|
DDoS filter for safeguarding SSL connections
In terms of defense against SSL-encrypted attacks, the proxies in the Link11 infrastructure are both destinations for legitimate communication and a potential point of attack. To provide the best possible protection, all Link11 proxies are located within a network protected by the Link11 infrastructure protection service, which analyzes the network traffic (layer 3-7) toward the web protection infrastructure without any knowledge of the encrypted contents.
Flow of communication – diagram:
When using Link11’s cloud-based web protection service for SSL, protection of sensitive and personal information from unauthorized access is ensured at all times. Critical elements such as the certificate/key combination are encrypted with the best methods available and stored securely according to the latest standards, which precludes any access by third parties.
(1) Google: HTTPS encryption on the web