An SSL flood is a form of Distributed Denial-of-Service (DDoS) attack that takes aim at the handshake process associated with Secure Sockets Layer (SSL)\/Transport Layer Security (TLS)<\/a>. It works by overwhelming a server with a wide array of SSL handshake requests.<\/p>\n\n\n\n The several sets of potential SSL handshake requests are at a certain point too intense for servers to handle. <\/p>\n\n\n\n SSL\/TLS handshakes<\/a> are an intensive process and require a great deal of coupled manipulation of server processing power as they result in synchronous operations directly in the server’s CPU and memory.<\/p>\n\n\n\n With a means to slow down or shut down servers outright and attack at least a portion of it with objections occurring with forced resolution based on SSL handshake request methods, these malignant clients can rapidly exhaust their own servers.<\/p>\n\n\n\n In addition, as a result of the reliance on this type of script or malicious initiation on a DDOS response through SSL flood-for-attack, it presents a specific form of aggressive locomotive impact against server-side resources as SSL is designed to provide usable encrypted channels between clients and server applications.<\/p>\n\n\n\n Renegotiation is another form of SSL\/TLS that takes the original ongoing cryptographic parameters established between clients and server characterizations to renew their origination at later times.<\/p>\n\n\n\n Although renegotiation is useful for the purposes of furthering the key or needing to rewrite the encryption parameters for mid-session requests, attackers that exploited the renegotiation model inclusively for SSL handshake request ground, have taken advantage through factors on both.<\/p>\n\n\n\n An SSL flood is a type of Distributed Denial-of-Service (DDoS) attack that targets the Secure Sockets Layer (SSL)\/Transport Layer Security (TLS) handshake process.<\/p>\n\n\n\n During this attack, an adversary floods a server with a massive volume of SSL handshake requests, overwhelming its resources.<\/p>\n\n\n\n Since SSL\/TLS handshakes are computationally intensive and require significant server-side processing power, even a relatively small number of malicious clients can exhaust the server’s CPU and memory, leading to slowdowns or complete service outages.<\/p>\n\n\n\n SSL floods are particularly dangerous because they exploit the very technology designed to provide secure, encrypted communication between clients and servers.<\/p>\n\n\n\n SSL flood attacks take advantage of the asymmetric resource usage of the SSL\/TLS handshake process to deplete a server’s resources.<\/p>\n\n\n\n Unlike traditional DDoS attacks, such as a flood of request packets or bandwidth consumption, an SSL flood presents the more sophisticated approach of exhausting a server’s computation resources through an attack.<\/p>\n\n\n\n It is a simplified process consisting of multiple steps that lead to exhaustion of the server’s resources and functioning properly:<\/strong><\/p>\n\n\n\n The attack starts when the malicious client connects to the server with a normal SSL\/TLS handshake. At this stage, nothing looks unusual.<\/p>\n\n\n\n The malicious client sends the “ClientHello” message to start the secure session and the server responds with its certificate and other cryptographic parameters.<\/p>\n\n\n\n This is a critical step because it provides the opportunity to fabricate the presence of legitimate traffic making it much tougher for security systems to quickly distinguish the compromised connections from the legitimate users.<\/p>\n\n\n\n Instead of completing a normal data transfer, the attacker periodically initiates more SSL handshakes or in some cases, takes advantage of SSL renegotiation.<\/p>\n\n\n\n Each handshake or renegotiation generates a new server-side processor utilization since it is all resource-intensive work.<\/p>\n\n\n\n Attackers accomplish this either by opening up new SSL connections rapidly, or by continuing to execute renegotiation on existing connections.<\/p>\n\n\n\n In any case, the server finds itself continually responding to a stream of server-side processing resources as the handshakes or renegotiation never end; this leads to a flood of loads with cryptographic operations.<\/p>\n\n\n\n The SSL\/TLS handshake operation by the server including all components is resource-intensive.<\/p>\n\n\n\n The costs are as follows when processing an SSL handshake: <\/strong><\/p>\n\n\n\n The key will be exchanged, server will perform and validate the client certificate, and server will validate the digital signature to provide a response while setting one or more parameters to establish symmetric keys<\/a>.<\/p>\n\n\n\n Although these costs only involve client resources to initiate the handshake, nearly all the server processing costs rest with the server.<\/p>\n\n\n\n With each new handshake or renegotiation request, resources are rapidly exhausted from CPU cycles, memory, and network resources.<\/p>\n\n\n\n The SSL\/TLS handshake operation by the server including all components – is resource-intensive.<\/p>\n\n\n\n The costs are as follows when processing an SSL handshake: the key will be exchanged, server will perform and validate the client certificate, and server will validate the digital signature to provide a response while setting one or more parameters to establish symmetric keys.<\/p>\n\n\n\n Although these costs only involve client resources to initiate the handshake, nearly all the server processing costs rest with the server.<\/p>\n\n\n\n With each new handshake or renegotiation request, resources are rapidly exhausted from CPU cycles, memory, and network resources.<\/p>\n\n\n\n In a SSL handshake flood, the attacker sends many new SSL\/TLS connections to the target server in rapid succession.<\/p>\n\n\n\n Each connection request forces the server to perform a full handshake, which internally includes CPU-intensive tasks such as key generation, certificate exchange, and encryption negotiation.<\/p>\n\n\n\n The cryptographic effort is much greater on the server-side rather than the client-side. Therefore, a relatively small amount of SSL Handshake requests can severely take your server’s resources.<\/p>\n\n\n\n The attacker doesn’t even have to finish the handshake, or send any data after his request is sent. The only goal is to keep the server busy handling handshake requests and thus degrade the service, or lock it up completely.<\/p>\n\n\n\n SSL renegotiation attack is one that comes on the back of an already secure connection. After the handshake was completed, a malicious client will continually request new SSL renegotiation from the server.<\/p>\n\n\n\n Renegotiation is a standard feature of SSL\/TLS that is designed to support changing encryption parameters in an established session.<\/p>\n\n\n\n Because the server and the malicious client are both connected already, the malicious client can repeatedly make the server successfully renegotiate expensive cryptographic operations.<\/p>\n\n\n\n Each renegotiation of the existing connection is equal to the cost of a new connection, but by doing this in an established session, it can bypass some very basic connection filters and rates on a per IP basis.<\/p>\n\n\n\n This variant of a SSL flood is very dangerous, as it is stealthier and more difficult to detect than a plain connection flood.<\/p>\n\n\n\n In this version of the SSL flood, the attackers use many IP addresses controlled by a botnet a network of compromised devices controlled by the attackers to launch a distributed SSL attack.<\/p>\n\n\n\n Rather than have a single host consume resources from the server by making multiple SSL requests simultaneously, thousands of bots around the world can initiate SSL\/TLS connections or renegotiation requests at the same time.<\/p>\n\n\n\n Because these SSL requests come from thousands of devices with legitimate geographical locations behind seemingly legitimate IP addresses, the target server can have a difficult time distinguishing malicious traffic from legitimate users.<\/p>\n\n\n\n Most traditional DDoS mitigation techniques such as IP blacklisting or geo-blocking based on a geographic location overall cannot help the target server.<\/p>\n\n\n\n In this flavor of an SSL flood, an attacker sends SSL handshake requests to the server with corrupted, expired, or, generally, invalid certificates. The server must still attempt to resolve the certificate in manners defined by the process of security management.<\/p>\n\n\n\n Recommended:<\/strong> How to Solve the Invalid SSL \/TLS Certificate Error?<\/a><\/p>\n\n\n\n The resolution process consumes large amounts of resources because the server must parse the certificate, check for expiration, verify digital signatures, and validate certificate chains.<\/p>\n\n\n\n Despite the server being forced to deny these requests, the overall resource consumption could still be significant from the point of view that validation still occurred. The cumulative cost for each request adds up they take time and processing power.<\/p>\n\n\n\n When this is repeated at scale, it could easily cripple the server, especially if it synchronously validates the SSL certificate.<\/p>\n\n\n\n SSL renegotiation attacks are a dangerous category of SSL flood attacks that exploit the computational asymmetry when both clients and servers begin the SSL\/TLS handshake and renegotiation.<\/p>\n\n\n\n Each renegotiation requires a significant amount of computation by the server for cryptographic tasks, and a large number of SSL clients can easily overload the CPU and memory of the server with only modest client effort.<\/p>\n\n\n\n The good news is there are several means of mitigating and preventing SSL renegotiation attacks. <\/p>\n\n\n\n Below are 10 very useful and actionable techniques including to protect your infrastructures from SSL Renegotiation Abuse:<\/strong><\/p>\n\n\n\n One of the easiest and most effective ways to mitigate attacks and reduce risks is to simply disable SSL or TLS renegotiation on your servers if your environment does not necessitate performing renegotiation. <\/p>\n\n\n\n Also Read:<\/strong> Top 10 SSL\/TLS Misconfigurations, Risks and It\u2019s Solutions<\/a><\/p>\n\n\n\n SSL (or TLS) renegotiation was introduced to provide mid-session re-authentication, or to change encryption parameters.<\/p>\n\n\n\n For most web applications today, renegotiation has no real value. By turning off the capability at the server or application layer you completely mitigate this as an attack vector.<\/p>\n\n\n\n Most web servers and load balancers (NGINX, Apache, HAProxy, etc.) have configuration settings that allow you to disable renegotiation in this manner so you can eliminate this potential threat.<\/p>\n\n\n\n By making the modification to your configuration, you have effectively reduced the risk surface for these denial-of-service attacks significantly.<\/p>\n\n\n\n Another important strategy is to rate limit SSL handshakes, and attempts to renegotiate. The concept is to track and limit how many times a client can initiate an SSL session, or how many renegotiation attempts they can make in a given time window.<\/p>\n\n\n\n For example<\/strong>, you could limit your server or proxy to five renegotiation attempts per IP in one minute. Once (or if) that limit is surpassed, the server can throttle or block the requesting IP.<\/p>\n\n\n\n This allows attackers to scale their attack and come up against significant roadblocks, well before they could trigger countermeasures from your defence.<\/p>\n\n\n\n Rate limiting can be especially useful in instances where complete disabling of renegotiation is not possible, or where applications require renegotiation to function.<\/p>\n\n\n\n To reduce the burden on backend servers, you may elect to adopt either a reverse proxy, or a standalone SSL offloading<\/a> appliance capable of offloading the “burden” to the edge.<\/p>\n\n\n\n These reverse-proxies, or SSL offloading appliances, terminate the SSL connections at the edge of your datacenter and allow the traffic to flow unencrypted (or re-encrypted) back to the internal network.<\/p>\n\n\n\n The reverse proxy handles all of the SSL\/TLS handshakes which has the added benefit of providing another layer of protection between the client and application servers.<\/p>\n\n\n\n This also improves performance and limits the attack surface of the core infrastructure to just the “SSL renegotiation” attack vectors. Companies such as NGINX, HAProxy, F5, AWS Elastic Load Balancer all provide strong SSL offloading solutions.<\/p>\n\n\n\n Modern Web Application Firewalls (WAFs) have matured to include protections from SSL flood attacks, including attacks that utilize renegotiation.<\/p>\n\n\n\n WAFs can detect your incoming SSL traffic patterns and apply behavioral inspections to mitigate these malicious behavior. WAFs can also terminate SSL sessions that they determine to be suspicious.<\/p>\n\n\n\n WAFs have the ability to detect renegotiation attempts that exceed a predetermined threshold, malformed certificates floods, or handshake delays and\/or deviations.<\/p>\n\n\n\n When combined with your reverse proxy\/edge appliance, WAFs act as an intelligent barrier capable of filtering out bad SSL behavior before it reaches your backend.<\/p>\n\n\n\n Solutions from organizations like Cloudflare, AWS WAF, Imperva, and Fortinet offer traffic inspection capabilities that are SSL-aware and help mitigate application-layer DDoS attacks.<\/p>\n\n\n\n Using some type of behavioral analytics tool set can significantly improve your capabilities to detect and respond to SSL renegotiation attacks in real-time.<\/p>\n\n\n\n Behavioral analytics tools use machine learning and traffic baselines to recognize abnormal behaviors related to SSL such as renegotiation frequency and handshake duration.<\/p>\n\n\n\n In cases of abnormal behavior, the systems can either automatically block offending IPs or issue challenges.<\/p>\n\n\n\n Behavioral analysis and anomaly detection are most effective against botnet distributed attacks where each instance of attack is slightly different when they generate traffic.<\/p>\n\n\n\n Finally, organizations that integrate behavioral analysis and anomaly detection with SIEM or IDS or IPS solutions can adopt a smarter and more adaptive security posture.<\/p>\n\n\n\n A number of the older versions of SSL and TLS include a number of known vulnerabilities and weak renegotiation handling logic.<\/p>\n\n\n\n When you upgrade your servers and applications to support TLS 1.2 or TLS 1.3<\/a> you not only benefit from more robust cryptographic algorithms, but you are also driving down the chances that exploit attackers may take advantage of renegotiation issues for abuse.<\/p>\n\n\n\n It is worth noting that with TLS 1.3, the protocol eliminated renegotiation support thereby removing that particular avenue of attack.<\/p>\n\n\n\n Also Read:<\/strong> List of TLS Versions: Which is the Latest TLS Version?<\/a><\/p>\n\n\n\n It is also important to ensure you have disabled any deprecated protocols including SSL: SSL 2.0, SSL 3.0, and TLS 1.0 at the configuration level. Many of the latest web servers will let you set minimum protocol versions with a simple configuration setup.<\/p>\n\n\n\n In certain situations, particularly in publicly accessible web portals or APIs, using challenge-response collections like CAPTCHA can deter or block automated attack tools like scrapers or brute-forcers.<\/p>\n\n\n\n For example, you can implement a logic flow before, or even early in, establishing SSL sessions, to serve a CAPTCHA challenge to verify whether there has been active human interaction.<\/p>\n\n\n\n This may not work for every use case or all environments particularly in API-heavy environments however implementing CAPTCHA is a strong approach for login pages or websites that have frequently been attacked by bots.<\/p>\n\n\n\n CAPTCHA can be used along with some behavioral thresholds to slow or block bots attempting to exploit renegotiation vulnerabilities.<\/p>\n\n\n\n Visibility is the key to any defense. You should also have real-time monitoring of SSL metrics, including handshake\/sec, average handshake time, renegotiation requests, and CPU usage for cryptographic processes.<\/p>\n\n\n\n By continuously observing SSL metrics, you can easily spot unusual increases in your volume counts that could indicate a flood attack is in process. In addition, centralizing SSL logs into a SIEM enhances your reporting and alerting with correlation.<\/p>\n\n\n\n Proactive monitoring is valuable for early detection; it is also useful for forensics to understand attack patterns and vector analysis.<\/p>\n\n\n\n Many frequently observed SSL renegotiation attacks also originate from botnets available in fixed geographic void regions or well-known bad IP address ranges. You can partially mitigate risks associated with bot-netted attacks through geo-fencing.<\/p>\n\n\n\n Define a geo-fence to limit application access to only specific countries or regions where the user demographic base is located.<\/p>\n\n\n\n In addition to geo-fencing, there are IP reputation databases that exist like AbuseIPDB, Cisco Talos, and Spamhaus that let you filter and block traffic from known-naughty IP addresses.<\/p>\n\n\n\n This can be used as low hanging fruit at the firewall level, reverse proxy, or CDN. Though at a firewall or CDN level, I can tell you it will help remove a portion of “noise” from opportunistic attackers and scanning bots.<\/p>\n\n\n\n If your organization is concerned about continuous threats, then considering a cloud-based DDoS mitigation provider, such as Cloudflare, AWS Shield, Akamai Kona or Google Cloud Armor is a good idea.<\/p>\n\n\n\n Also Read:<\/strong> What Is SSL Passthrough? How does TLS Passthrough Work?<\/a><\/p>\n\n\n\n These providers have the ability to pass SSL traffic through their platforms globally, have built-in advanced filtering, bot management, and even threat intelligence. They are built to absorb massive floods and provide availability, even in a complex distributed SSL renegotiation attack.<\/p>\n\n\n\n The scalability of the cloud shifts the burden off of your infrastructure while your legitimate users still have access.<\/p>\n\n\n\n Don’t wait for a denial-of-service incident to discover gaps in your security. Get ideal web security solution like SSL Encryption<\/a> today, optimized for performance, security against modern exploits, and available with 24\/7 support.<\/p>\n","protected":false},"excerpt":{"rendered":"How Attackers Exploit Renegotiation?<\/h2>\n\n\n\n
How Do SSL Flood Attacks Work?<\/h2>\n\n\n\n
Initial Connection<\/h3>\n\n\n\n
Handshake Overload<\/h3>\n\n\n\n
Resource Consumption<\/h3>\n\n\n\n
Server Exhaustion<\/h3>\n\n\n\n
Types of SSL Flood Attacks<\/h2>\n\n\n\n
SSL Handshake Flood<\/h3>\n\n\n\n
SSL Renegotiation Attack<\/h3>\n\n\n\n
SSL Exhaustion via Botnets<\/h3>\n\n\n\n
SSL Abuse with Invalid Certificates<\/h3>\n\n\n\n
How to Prevent an SSL Renegotiation Attack?<\/h2>\n\n\n\n
Disable SSL\/TLS Renegotiation<\/h3>\n\n\n\n
Rate Limiting SSL Handshakes and Renegotiations<\/h3>\n\n\n\n
Use Reverse Proxies or SSL Offloading<\/h3>\n\n\n\n
Implement Web Application Firewalls<\/h3>\n\n\n\n
Behavioral Analysis and Anomaly Detection<\/h3>\n\n\n\n
Upgrade to Modern TLS Versions<\/h3>\n\n\n\n
Deploy CAPTCHA or Challenge-Response Systems<\/h3>\n\n\n\n
Monitor SSL Metrics and Logs Proactively<\/h3>\n\n\n\n
Geo-Fencing and IP Reputation Filtering<\/h3>\n\n\n\n
Use Cloud-Based DDoS Protection Services<\/h3>\n\n\n\n
Conclusion<\/h2>\n\n\n\n