SSL: Protective Technology Turned Attack Vector

It’s been over 20 years since the earliest versions of the Secure Socket Layer (SSL)
protocol emerged from a team of engineers at Netscape Communications. As the Internet and more specifically the World Wide Web began its precipitous climb in the early 1990’s these engineers recognized that to drive deeper interactions online, a standard for securing communications would need to be widely adopted.

As is always the trend, mass adoption of certain technologies is followed closely by efforts to exploit its wide use through a number of security threats. SSL is no exception to this rule, and has experienced a large number of highly publicized vulnerabilities that force users to move to new, more secure versions and ultimately a replacement protocol such as Transport Layer Security (TLS).

However, exploits of newly identified vulnerabilities are not the only way that SSL adoption is being used as a weapon in the hands of malicious attackers and adversaries behind cyber threats. SSL is increasingly being used to mask and further complicate attack traffic detection in both network and application level threats.

SSL Attacks

SSL attacks are popular among attackers as it only requires a small number of packets to cause denial of service for a fairly large service. Attackers launch attacks that use SSL because each SSL session handshake consumes 15 times more resources from the server side than from the client side, meaning the attack has exponentially increased in size without requiring additional bots or bandwidth. As a result of these amplification effects, even a small attack can result in crippling damage.

[You may also like: Detecting and Mitigating HTTPS Floods…Without Decryption Keys]

SSL-based attacks take many forms, including:

Encrypted SYN floods. These attacks are similar in nature to standard, non-encrypted SYN flood attacks by exhausting resources in place to complete the SYN-ACK handshake. The difference is these attacks further complicate the challenge by encrypting traffic and forcing use of SSL handshake resources.

SSL Renegotiation. Work by initiating a regular SSL handshake, and immediately requesting for the renegotiation of the encryption key. The tool constantly repeats this renegotiation request until all server resources have been exhausted.

HTTPS Floods. Generate floods of encrypted HTTP traffic, often as part of multi-vector attack campaigns. Compounding the impact of “normal” HTTP Floods, encrypted HTTP attacks add several other challenges, such as the burden of encryption and decryption mechanisms.

Encrypted web application attacks. Multi-vector attack campaigns also increasingly leverage non-DoS, web application logic attacks. By encrypting the traffic, these attacks often pass through both DDoS and web application protections undetected.

Complicating Detection & Mitigation

In the same way SSL and encryption protect the integrity of legitimate communications, it equally obfuscates many attributes of traffic used to determine if it malicious versus legitimate. Identifying attack traffic within encrypted traffic flows is akin to finding a needle in a haystack in the dark. Most cyber-attack solutions struggle to identify potentially malicious traffic from encrypted traffic sources and isolate it for further analysis (and potential mitigation).

The other major advantage that SSL attacks offer to attackers is the ability to put significant computing stress on network and application infrastructures targeted. The process of decrypting and re-encrypting SSL traffic increases the requirements of processing the traffic, in many cases beyond the functional performance of devices used for attack mitigation.

[You may also like: HTTPS: The Myth of Secure Encrypted Traffic Exposed]

Most are inline and stateful and cannot handle SSL encrypted attacks, making it vulnerable to SSL flood attacks. Fewer of these solutions can be deployed outof-path, which is a necessity for providing protection while limiting impact on legitimate users.

Many solutions that can do some level of decryption tend to rely on rate limiting the rate of request, which results in dropped legitimate traffic and effectively completes the attack. Finally, many solutions require the customer to share actual server certificates, which complicates implementation, certificate management and forces customers to share private keys for protection in the cloud.

Protecting Against SSL Attacks

The unfortunate reality is that the majority of DDoS attack protection solutions only provide protection for certain types of attacks, and in many cases struggle with SSL attacks. The bottom line is that to provide effective protection, solutions need to delivery full attack vector coverage (including SSL), high scalability to meet the growing demands of the consumer, and innovative ways to minimize if not eliminate these threats.

Consider the following when evaluating a solution:

• Does it meet the needs of high capacity mitigation solutions?
• Does it support all common versions of SSL and TLS?
• Does it isolate suspicious encrypted traffic using behavioral analysis to limit legitimate user impact?
• Can it provide advanced challenges/response mechanisms to validate encrypted traffic flagged as suspicious but only impacts the initial user session?
• Does it offer asymmetric deployment, where only ingress encrypted traffic passes through the mitigation engine?