Due to the growing need for online services, for practically every organization in any field and industry, enterprises constantly try to minimize risk and protect their services. Among the many strategies and technologies incorporated into protecting online services, SSL is a basic and essential security measure.
Secure Sockets Layer (SSL) is a cryptographic protocol that controls encryption and transmission of data between two points. Sometimes referred to as SSL Visibility, SSL Decryption decrypts traffic and routes it to various inspection tools to identify threats –targeting both inbound and outbound applications from users to the internet.
Implementing SSL decryption is a common and useful tool for security teams to protect end users, customers, and the organization’s data. Using SSL decryption will prevent data breaches, monitor outgoing information from within the organization, meet regulatory compliance requirements, and support a multi-layered security protocol.
Is SSL Decryption DDoS-Vulnerable?
Security teams that use SSL decryption must take into account that there are several common DDoS vulnerabilities that we, at MazeBolt, continue to uncover when conducting continuous and non-disruptive DDoS testing – no matter the organization or the industry it belongs to.
These vulnerabilities are a common gateway for two major DDoS attack vectors: the THC-SSL Attack and the SSL Negotiation/ Re-Negotiation Attack.
THC-SSL Attack
The THC-SSL attack uses a single TCP connection to constantly renegotiate new encryption keys; This attack vector is unique in that with one single connection, the server “allows” the client to request a new SSL handshake in the same TCP connection.
The THC-SSL attack will work effectively on a server, which will allow the clients to initiate a new handshake at the time of their choosing – but leaving such behavior in the server is considered a vulnerability to DDoS attacks.
First, the attacker initiates a connection to the server using a TCP handshake. Once established, the attacker will begin the attack. If the server hasn’t disabled client-initiated cipher renegotiation, the attacker will request a cipher spec change. The server will then compute what is required for the cipher spec change and send the data to the client – but the client is the attacker.
As soon as the server is done, the attacker will request another cipher spec change and will continue to do so, at a high rate. The PCAP will be filtered for the attacker‘s single source IP and for the SSL content type that matches the renegotiation request.
The THC-SSL attack is such a simple yet devastating attack, that a single computer can take down a web server because the DDoS attacker gains a direct route to the victim’s CPU. The computations required for the renegotiation are expensive, and the attacker can trigger those computations with a single PSH-ACK packet, without ever needing to initiate a new TCP or SSL connection.
Discover more elusive attack vectors that evade DDoS protection.
SSL Negotiation/ Re-Negotiation Attack
The SSL Negotiation attack is a DDoS attack that attempts to establish many new SSL handshakes with the targeted server. Each handshake is a new TCP connection that affects the target server by opening and closing many such connections.
SSL/TLS handshakes can get up to 15 times more CPU-intensive on the server than on the client, so while the server may not be down following this attack, it may be unable to establish any new SSL connections, effectively leaving that SSL service unavailable. It is important to note that technically, this attack may be referred to as a Layer 6 attack and not Layer 7.
Following the initial TCP handshake, the server will respond with a “server Hello” packet which contains the Cipher Suite chosen by the server from the list of cipher suites supported by the client, and also the session ID, as well as a random string. Next, client key exchange will take place, using the server’s public key.
Once done with the key exchange, all messages passed subsequently will be encrypted. Each key exchange takes about 15 times more computing power on the server, due to its need to handle the new client SSL handshake initiation. Another reason is that a new TCP session is needed for all the SSL daemon server side. Thus, the attack saturates both the server’s CPU and the TCP session table.
DDoS Security’s Critical Breakthrough
Even with the best DDoS protection in place, and using the most advanced and up-to-date protocols, including SSL decryption, the average DDoS vulnerability rate for organizations with protection systems is anywhere between 30-75%.
SSL decryption is not a guaranteed method to protect against DDoS attacks, and the two attack vectors mentioned in this article take advantage of common hidden vulnerabilities.
Organizations are left vulnerable due to unknown attack vectors that evolve daily in direct response to ever-changing digital environments. So, currently, most organizations are practically flying blind, while the average number of DDoS attacks per day is well over 23,000 – on enterprises alone.
Organizations and their protection vendors must perform continuous DDoS testing on live environments to uncover misconfigurations and hidden vulnerabilities, prioritize their remediation, and validate that the fixes were performed correctly.
Simply put – go from reactive to preemptive in order to stay ahead of the threat curve.
