Webserver DDOS protection without giving away private keys (https, tls, ssl)

Question

What are the possible ways to protect an organization's web servers from a DDoS attack without giving away your web server's https private keys?

Many of the common solutions for DDoS protection of a web server (eg CloudFlare) require you to give a third party either your https private key or (worse) give them the ability to mint their own valid certificate for your domain (eg control of your DNS for ACME).

I don't feel comfortable giving a 3rd party my website's private keys.

How can I protect my web servers from a DDoS attack without giving my private keys to a thrid party?

Answer 1

The reason 3rd party DDoS protection services require your private keys, is so they can actually inspect the traffic and act upon that.

Without that, they're just analyzing IP streams of encrypted data. DDoS protection is still possible in that case, but only really effective for all attacks based OSI layer 3 and 4. For example, UDP floods, TCP SYN attacks, specific hosts generating a lot of traffic, etc. can be detected and mitigated with no problem at all.

However, it's impossible to detect Layer 5-7 attacks, because that's all encrypted. So attacks on specific URLs can't be detected for example.

On-premises equipment can be a solution for doing the Layer 5-7 attacks yourself. However, for those Layer 3/4 attacks it isn't always a solution. For attacks small enough that they don't fill up your upstream connection(s) it could work, but not everyone is able to handle DDoS attacks of over 100Gbps in their own network, and in that case an external scrubbing centre could be a solution.

So if you really don't want to share your keys, combining a Layer 5-7 on-premises solution with a Layer 3-4 remote scrubbing center could be an interesting combination. That's from a technical perspective of course, there may be financial or other reasons not to do that. And everything depends on which type of DDoS attacks you want to protect against.

Answer 2

If you are after protection from DDoS—i.e. attacks that try to overwhelm your sever with too many requests—only, you don't need to give your TLS certificates to anybody.

Generally if you set up a simple load-balancer in a datacentre—that has a public IP and simply routes all traffic to the actual server—it will generally come with a basic DDoS protection already, because it is part of the datacentre's own defences.

The basic protection throttles the requests and sends the excess to a black hole using routing adjustment. That protects your server from overload, while trying to permit at least some legitimate traffic to still pass though some might be blocked if the client is too close to some nodes used in the attack.

Then a higher level of protection may be offered (e.g. Azure does) where you get more analytic information about the attack and some control over which traffic should be discarded, so your response team might try to minimize how many clients are caught in the crossfire, or take other specific actions.

A full reverse proxy that does TLS termination offers protections from other attacks, like stopping patterns commonly used in SQL injection or XSRF attempts. But those are other kinds of attacks, not DDoS.

If you don't want to use third party reverse proxy, you can get similar features by installing modsecurity (in nginx or apache) with OWASP Core Rule Set. I'd suggest still installing a separate nginx reverse proxy with the TLS keys, modsecurity and possibly authentication, and separate server with the actual application for a bit extra defense-in-depth.

Answer 3

Your key question is this:

How can I protect my web servers from a DDoS attack without giving my private keys to a third party?

But you already answer that yourself:

... or (worse) give them the ability to mint their own valid certificate for your domain (eg control of your DNS for ACME)

It's not clear why you think this is worse - it's much better to have separate certificates with their own private keys that are never transmitted anywhere, and which can be independently revoked, than a single certificate used in multiple places.

Possibly you're assuming that this will be a case of handing the service more passwords, which is unlikely to be the case.

In order to do anything with your traffic, a service needs to sit between the public internet and your servers. That means all your traffic is already flowing through their servers. This generally involves one of two things:

• Creating a CNAME for a specific sub-domain in your DNS that points to their servers.
• Using their name servers to host the DNS zone, so that they can use dynamic DNS resolution, and manage the apex record (which can't be a CNAME).

Once you have either of those in place, they do not need any further access to create a certificate for the domain. For instance CloudFlare's documentation says

There are several methods that are used to complete [the Domain Control Validation] process, the primary ones that Cloudflare works with are:

• HTTP Token
• CNAME DNS Record
• TXT DNS Record

The first of these is simplest: they intercept requests to a certain plain-text HTTP URL and serve the validation token requested by the Certificate Authority.

Ethically, they should not do this without your permission, but by pointing your DNS name at their servers, you are giving them complete control over what is served on that domain.

Answer 4

While it may be more difficult, you certainly can in-house your DDoS protection without having to give your private keys to a third party -- especially if you can quickly scale-up frontend web proxies (eg in a public or private cloud).

One example solution for how to provide your backend webservers DDoS protection without handing your https private keys to a third party is the solution that's used by many anonymous Onion Service providers: EndGame.

• https://github.com/onionltd/EndGame

Many security-critical websites that are hosted on Onion Services are too risk-averse to give a third party their private keys. While this is less of an issue for the most popular website on the darknet (Facebook), it should be avoided for Secure Drop endpoints from organizations like the BBC, NYT, ProPublica, etc.

EndGame is an on-prem DDoS mitigation tech developed for Onion Services that was released on GitHub in May 2020 by Onion Ltd. It uses nginx frontend proxies ("fronts") to put new website visitors in queues and require them to solve a CAPTCHA (generated with python).

After waiting some seconds, the user is presented with a CAPTCHA from one of the fronts. If the user solves the CAPTCHA correctly, then their session is forwarded to the actual Onion Service backend.

If the CAPTCHA works, then the DDoS will be mitigated against the backend, and the Onion Service administrator only needs to scale-up their fronts. EndGame's README recommends at least 3 fronts.

At the time of writing, EndGame is what's used in many popular anonymous Onion Services, such as the Elude Tech Collective and the Dread Forums.

EndGame's README says that it helps mitigate DDoS attacks, but that it "isn't perfect" and suggests that Tor developers should add a POW at the introduction point to make Onion Services more DDoS resilient

EndGame isn't perfect. It can't protect against introduction cell type attacks (the Tor project will need to add POW at the introduction points to fix that). But it does provide good protection and scaling which makes it much harder to take you down overall for whatever people throw at you.

source: https://github.com/onionltd/EndGame/blob/master/README.MD

Further Reading

For more information about protecting Onion Services from DDoS attacks, see the following articles published by the Tor Project:

• Jun 2022 https://status.torproject.org/issues/2022-06-09-network-ddos/
• Aug 2020 https://blog.torproject.org/stop-the-onion-denial/
• Jan 2014 https://blog.torproject.org/new-tor-denial-service-attacks-and-defenses/

See also https://tor.stackexchange.com/q/1181/31208