How to mitigate SSL based DDoS attacks?

Question

as you probably know the problem with SSL based DDoS attacks is, that the traffic cannot be analysed and filtered by a DDoS mitigation service provider such as Prolexic, Akamai, Radware, etc. without having the key to decrypt the traffic.

I recently spoke with on of the above mentioned companies employees (Lets say company A) and they said that the only way is to use one of their products, wich is located in your network and its purpose is to deliver content via ssl and send all traffic in plaintext to the defense solution (same company, also internal network) which then in turn gives the filtered "good traffic" to your internal webservers.

Other companies have the approach that you handout your ssl key to them, so they can decrypt and analyze your traffic and pass the clean traffic on to your servers.

Company A stated, that the later is a absolute nogo and that it shouldn't even be considered. Problem is, their solution can only filter as much traffic as your infrastructure and their appliance can handle while cloud solutions have much higher capacities.

So the question is, is there another way of mitigating SSL based DDoS attacks, is handing out your ssl key really that bad and why?

I know that there already was a question on "storing keys in the cloud - trusting the cloud provider vs. your own laptop, etc." so I'm sorry if some of this is a duplicate, but the answers there didn't really answer my question.

Answer 1

Let's clear up a couple of misconceptions:

• DDoS mitigation partners cannot work unless they can decrypt traffic

Yes, they can - they just can't do it as well, as the content is not visible, so the solutions which work on traffic flow will still work.

• Handing your key to a 3rd party is a bad thing

Not necessarily. In fact this is extremely common for large corporates - who typically have their infrastructure managed by 3rd parties anyway. What it does do is require that you replace some of your technical controls with contractual controls, and that you take greater oversight/audit responsibilities over the 3rd party.

Mitigation of the threat of the 3rd party misusing the key, or not protecting it is a straightforward one to assess and then provide a solution for.

Answer 2

SSL DDoS Attacks should be divided into two -

• Protocol misuse attacks - Such attacks exploit the protocol being used and can cause denial of service effect without completing the creation of secure connection (SSL in our case). A good example can be the THC-SSL-DOS which can be used to create repeating 'renegotiation' in the same connection, though never completing the creation of a secure channel.
  Protocol attacks, like the one mentioned above, do not require having keys. They can be mitigated with relatively simple protection measures as IPS signature, enforcement of server settings, or even dedicated DDoS appliances Pravail/Riorey/DefensePro/NSFocus/etc.

• SSL Traffic Floods - Here I refer to data that is being passed over the created secure channel. Without further information, these magnificent mitigation devices cannot distinguish between valid connections to malicious connections. They cannot even issue web challenge in an attempt to try and assess source legitimacy. So you are either stuck with nothing or some rate-limit protection - prone to false actions.

So, what can be done - Some appliances can be fed with the certificates or be connected to another appliance from same family (DefensPro-Alteon / Pravail-VSS) - where the sister product opens the encryption, and ddos device does what it does and the flow is allowed to continue or is blocked. Radware can issue a challenge on the initial encrypted request (and only on it). Arbor can continuously inspect encrypted traffic, and block suspicious traffic (no challenge). As long as you keep these machines at your place, the risks are rather low.

Some cloud services offer you to give them your keys. Not very recommended practice. However, Prolexic lately published they can live with temp-short-lived keys to achieve the same. This might be a sufficient solution, considering all other limitations and restrictions when dealing with secured (encrypted) traffic.

And last - is it bad to provide your key? In a very basic manner - Your key is important to secure your communications. If someone has your key she can theoretically 'read' your communications, or impersonate to you while communicating with others. However, as someone answered before me, you can practice sharing or having copies of your keys at different places. Depends on your infrastructure, on who manages your network, etc. Above all it relates to TRUST. If you trust this 'born yesterday' DDoS protection in the cloud service - go a head, give them your keys :). There are companies that can be trusted and that put many efforts into complying with all regulatory requirements. It doesnt provide 100% insurance, but frankly, nothing does.

Answer 3

All the vendors are going to give you the same answer: you need to hand over your key to them either for a cloud-based security product, or for a box that they supply that sits in your network. Either way you cannot completely mitigate the threat that the have your keys.

The alternative is to mitigate the threats posed by individual attacks by:

• Keeping your systems and applications up to date: many previously serious ddos attacks have been eliminated by OS and software updates
• Modifying your configurations: you can often tweak OS and applications to be much more resilient
• Offload SSL computations: there are several solutions in this area, often load balancers have crypto engines that can do the work

What you really need to do is perform (or have somebody perform) a threat analysis to find out your biggest concerns, then look for solutions to those. It may be a vendor solution is your best way forward, or you may be able to do just fine using tactical, zero or low cost solutions.

Answer 4

Ichilov's answer is more relevant.

Two non-vulnerable SSL Attacks

1. Send garbage data in place of pre-master secret (SSL Handshake flood)
2. Continuously re-negotiate the per-master secret from the handshake again & again

Hope Ichilov's explination is quite enough

Mitigation:

• Client puzzle can help to mitigate DDoS attacks. The client puzzle mechanism could be developed for protocol. It's based on Proof-Of-Work systems. For SSL an IETF Draft is available at http://www.ietf.org/id/draft-nygren-tls-client-puzzles-00.txt .Client-Puzzle mechanism is an intent-based security mechanism that doesn't simply eliminate malicious clients, but increases the attacker's cost. Also these mechanism are more effective against signature based mitigation, which employs IDS/IPS systems with enormous amount of rules.

• The other method is to outsource the computation of modular exponent, a highly resource intensive operation. A partial computation can be outsourced to a daemon system(s). Otherwise, a system with crypto-chip can be used. Outsourcing can improve the performance of the server, but doesn't eliminating malicious client.

I already developed client-puzzle mechanism to work with HTTP. Also I planned to develop for SSL. Hope, you might feel the article interesting. https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

Answer 5

There are ways and means to monitor TCP and SSL handshakes to determine bad behaviour ahead of actually decrypting / offloading.

Look at the client/server hello for non-RFC compliance and consider rate limitation for 'hello' floods based on this.

HTH.