You've embraced SSL/TLS because, well that's what your security folks told you to do right? So the sensitive parts of your website are now protected with SSL. You might even be using client certificates to authenticate connecting parties. Sounds great, but now you have new threats to defend against - the Distributed Denial of Service (DDoS) and application layer attacks over SSL.
DDoS attacks have been evolving in size and complexity though more thorough reconnaissance and refined targeting, utilising increasingly advanced and easily available attack tools. One example of targeted complexity is the chaotic actors on the internet using SSL against you. An emerging trend is for attackers to attack certain SSL handshake functions. A server will typically use 15 x more computing resources in the SSL negotiation than the attacking system. This in turn provides the attacker with excellent economical advantage and economies of scale in their attacks.
Furthermore, attackers are using SSL to tunnel HTTP attacks to the target server, knowing very well that most organisations encrypt end-to-end, and do not have solutions to inspect SSL encrypted traffic to effectively defend against the attacks.
Most security savvy organisations have been moving to terminating SSL at the perimeter of their data centre, through a variety of methods. For example, the use of Application Delivery Controllers (ADC's) and these do a wonderful job at off-loading SSL from the server, and if appropriately licensed, also offer Web Application Firewalls (WAF) to inspect the traffic for signs of attacks. An excellent combination, they increase performance and offer increased security. The challenge though, is that all the attack traffic needs to first get to your data centre before these devices can offer protection.
A small but well organised DDoS attack that targets both encrypted and unencrypted web content can easily exceed 3-4Gbs of sustained DDoS traffic. This volume of traffic will knock most organisations off the air, and even if it is not a volumetric DDoS attack, attacks at the application layer can easily consume back end resources without starving your network bandwidth. Some of these layer 7 attacks will easily exhaust the connection tables of your perimeter devices, rendering them ineffectual.
For reference, the largest DDoS attack ever recorded was that of a 124Gbps against a US government website back in July 2009.
What about clean pipes and ‘scrubbers’, they can deal with these attacks over SSL?
Generally speaking, clean pipe and scrubbing solutions work by rate limiting traffic based on traffic behaviour, so therefore limiting the number of connections from geography, IP address, protocol used, and so on. Once a condition is met then the clean pipe, the scrubbing solution will start to scrub the traffic by dropping packets.
The goal of these solutions is to reduce the volume of attack traffic to a volume where the customer’s data centre resources can effectively deal with it. However, unless the SSL attacks or application attacks tunnelled over SSL display some identifiable behaviour at the network layer, these solutions tend to be ineffective or mitigation techniques are too prone to false positives, making the mitigation disruptive to valid users. This was evident in a recent DDoS campaign where attackers would tunnel HTTP DDoS attacks over SSL, essentially overcoming DDoS defences.
These SSL attacks, when combined with volumetric network and application DDoS attacks, create a perfect storm, challenging current thinking and traditional approaches to defending against DDoS.
A distributed threat requires a distributed defence.
Sounds great, but what does that really mean? You need to push your security policy and countermeasures beyond the perimeter of your data centre and close to the source of the attack. In reality, only a cloud-based Intelligent Application Delivery Platform (ADP) that is optimised for security can offer this type of protection.
To achieve maximum protection and minimisation of false positives, your SSL protected content needs to be terminated within the ADP. This is necessary so the ADP is able to operate similarly as an ADC—offloading the SSL from the origin infrastructure and inspecting the application traffic for signs of attack traffic or violations of policy. A good ADP will also ensure that your traffic is then re-encrypted and forwarded back to the origin infrastructure, with unencrypted content only ever residing in protected memory on a secure bastion host.
But wait, if they terminate my SSL traffic, do I not have a data leakage and nonrepudiation risk? Depending on the ADP provider and how they manage the SSL certificates and corresponding private keys, the answer could be yes. There is no silver bullet, however a responsible ADP provider would never ask you for a private key. They would generate a key pair and submit to a public Certificate Authority (CA) for verification and signing. You should also have the flexibility to use whichever CA you prefer, and this model should always use a CA whose root and subordinate CA's are trusted by all major web browsers. This ensures that users of your service don't experience warnings about untrusted certificates.
If architected correctly, a good ADP provider should become an extension of your federated trust model, allowing you to retain full control and if need be revoke a certificate and migrate off their platform with minimal effort. It is absolutely imperative that you always maintain control and see the ADP provider as simply a custodian of an aspect of your digital realm, and enforcer of your security policy.