{ "id": "8791f2ba-568e-4309-aa0c-c534cd505c23", "created_at": "2026-04-06T02:11:55.051935Z", "updated_at": "2026-04-10T13:11:55.071126Z", "deleted_at": null, "sha1_hash": "0e347cb2f13fdc3e67ab21e98e4412f21f9ecb9e", "title": "DDoS Attacks on SSL: Something Old, Something New", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 156666, "plain_text": "DDoS Attacks on SSL: Something Old, Something New\r\nBy ASERT team\r\nPublished: 2012-04-24 · Archived: 2026-04-06 02:09:06 UTC\r\nSSL (or TLS) secures web services such as banking, online purchases, email and remote access. Popular services\r\nsuch as Twitter, Hotmail and Facebook are increasingly migrating to SSL to improve security and address privacy\r\nconcerns. As more transactions and services are protected by SSL, DDoS attacks on SSL secured services are on\r\nthe rise and are justifiably getting more attention. Some of these attacks are actually standard flood and TCP\r\nconnection based attacks that have been used for years to disrupt both secured and clear text services. We also see\r\nattacks targeting SSL itself. Let’s take a look at how attackers are using old and new methods to disrupt SSL\r\nprotected services.\r\nCommunication between a client out on the internet and a data center server begins (in most cases) with the\r\ntraditional TCP handshake. This is true for both SSL secured communications and non-secured.\r\nThe TCP layer is a very common target of DDoS. There are various flavors of these attacks but they share one\r\naspect in common – the attack target is the capacity of the infrastructure to support concurrent TCP connections.\r\nRegardless of how many servers or how robust the infrastructure (firewalls, load balancers) there is a finite\r\ncapacity to maintain TCP connections. One of the most common of this type of attack is the well-known Syn\r\nFlood, where attackers initiate enough connection open requests (“SYNs”) without completing the handshake to\r\nexhaust that capacity. A variant of this method of attack is for botnetted hosts to open large numbers of TCP\r\nhttps://www.netscout.com/blog/asert/ddos-attacks-ssl-something-old-something-new\r\nPage 1 of 4\n\nconnections simultaneously and actually complete the TCP handshake, thereby bypassing standard Syn Flood\r\nprotections. Another means of bypassing traditional SYN-flood protections is Slowloris and its variants, which\r\nalso complete the TCP handshake but then send a request to the server very slowly, one byte at a time, never\r\nactually completing the request.\r\nOnce the TCP handshake is completed there is a network layer session available for the SSL handshake to take\r\nplace. The purpose of this exchange is to validate the authenticity of the parties and to establish the encryption key\r\nand options that will secure the subsequent communications. The SSL handshake is shown below.\r\nThere are numerous known and potential attacks which exploit the SSL handshake to exhaust server resources.\r\nThe Pushdo botnet accomplishes this quite easily by sending garbage data to a target SSL server. The SSL\r\nprotocol is computationally expensive and it generates extra workload on the server to process garbage data as a\r\nlegitimate handshake. Firewalls don’t help in this case because the clients have completed the TCP handshake and\r\nare sending traffic to an allowed service.\r\nAnother SSL-based attack tool is the THC-SSL-DOS tool, which works by completing a normal SSL handshake\r\nbut then immediately requests a renegotiation of the encryption method. As soon as the renegotiation completes, it\r\nrequests another renegotiation, and so on. If the server has SSL renegotiation disabled (a standard security best\r\npractice), then the tool simply closes the SSL connection as soon as the negotiation completes and opens a new\r\nhttps://www.netscout.com/blog/asert/ddos-attacks-ssl-something-old-something-new\r\nPage 2 of 4\n\nconnection to start the negotiation process all over again. This is extremely computationally expensive and is\r\neffective at making services unavailable to legitimate users due to resource exhaustion. There are numerous other\r\npotential attacks that target various aspects of the SSL negotiation process to cause server overload and denial of\r\nservice. The diagram below is a simplified view of the infrastructure data centers use to provide ecommerce, email\r\nor other services protected by SSL.\r\nWhat is the DDoS attack surface in this infrastructure? First off, the entire data center can be cut off from the\r\noutside world through very high volume traffic floods that saturate the incoming links from the internet. Assuming\r\nthe data center has a provider capable of detecting and screening those types of attacks, what comes next? The\r\nfirewall is the next target, prone to TCP state exhaustion attacks. Similarly the load balancer/SSL Offload devices\r\nare vulnerable. Both maintain tables that track ongoing TCP sessions. In the face of TCP based attacks these\r\ndevices may become overwhelmed, causing them to stop accepting new connections, remove existing connections\r\nor even crash. These actions effectively accomplish the purpose of the attack. Further up the stack, devices\r\nsupporting SSL and actual application services are attack targets in themselves and have additional application-layer vulnerabilities such as the SSL attacks discussed above. Most firewalls, ADCs, and WAFs include some\r\nDDoS protections yet many high end data centers with the most up to date infrastructure have fallen victim to\r\nDDoS.\r\nWhy do DDoS attacks continue to succeed?\r\nDetection is reactive – if attacks are detected based on session tables filling up, server response times\r\nrising, etc.\r\nDDoS attacks (by definition) are distributed. What is normal and acceptable behavior from a single session\r\nbecomes an attack when repeated by thousands of sources. Firewalls, ADCs view traffic on a session by\r\nsession basis. •\r\nBlended attacks are effective because each element in the infrastructure is dedicated to performing a\r\nparticular function.\r\nThere is a lot of NAT out there. DDoS protections built into firewalls and ADCs are heavily based on\r\nbehavioral attributes of the requesting hosts – e.g. how many sessions from a given source IP. With more\r\nand more NAT’d and proxied sources (inside enterprise networks, behind carrier grade NAT, Content\r\nDelivery Services) behavioral methods have a hard time teasing out the bad from the good.\r\nWhat is Arbor’s approach?\r\nhttps://www.netscout.com/blog/asert/ddos-attacks-ssl-something-old-something-new\r\nPage 3 of 4\n\nPut DDoS protection at the data center edge – in front of the DDoS attack surface.\r\nBe as invisible as possible – not part of the attack surface.\r\nMultiple levels of detection. Use individual host behavior, aggregate behavior of multiple hosts, known\r\nsignatures and attributes of botnet traffic, IP location, reputation, etc.\r\nMultiple levels of mitigation. Packet based, header based, behavioral, challenge response techniques that\r\nindentify infected hosts and spoofed addresses, white and black lists.\r\nAutomate as much as possible, provide manual controls, and report on what is going on (where traffic is\r\ncoming from, going where, what is requested, rates, what was blocked, what was passed). In short, stop\r\nattacks before they reach the attack surface and enable the data center to do what it was designed for.\r\nSource: https://www.netscout.com/blog/asert/ddos-attacks-ssl-something-old-something-new\r\nhttps://www.netscout.com/blog/asert/ddos-attacks-ssl-something-old-something-new\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://www.netscout.com/blog/asert/ddos-attacks-ssl-something-old-something-new" ], "report_names": [ "ddos-attacks-ssl-something-old-something-new" ], "threat_actors": [], "ts_created_at": 1775441515, "ts_updated_at": 1775826715, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/0e347cb2f13fdc3e67ab21e98e4412f21f9ecb9e.pdf", "text": "https://archive.orkl.eu/0e347cb2f13fdc3e67ab21e98e4412f21f9ecb9e.txt", "img": "https://archive.orkl.eu/0e347cb2f13fdc3e67ab21e98e4412f21f9ecb9e.jpg" } }