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?

  • 2
    You can't really. The whole point of the private key is that if you don't have the key, you aren't the domain, you're an attacker who sets off the flashing lights and sirens. Commented Mar 24, 2021 at 15:19
  • Right, so what about self-hosted on-prem solutions? Commented Mar 24, 2021 at 15:21
  • 10
    To protect yourself from a DDOS you need more bandwidth than the attacker. The biggest ever DDoS had 1000 Gbps of bandwidth. Do you? Commented Mar 24, 2021 at 16:29
  • 3
    Have a look at Keyless SSL. The CDN will still be able to inspect and modify your traffic though, this is the point. Generic DDoS protection not specific to HTTP does not need the keys in the first place, but can only address generic attacks then, not web server specific ones. Commented Mar 24, 2021 at 17:40
  • @user253751, to protect from DDoS you need the bandwidth, but you are not going to look into the packets at all, because you still don't have the power, so you don't need the keys.
    – Jan Hudec
    Commented Mar 25, 2021 at 9:14

4 Answers 4


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.

  • 2
    (I ask this knowing nothing about CloudFlare or other service providers:) CloudFlare must offer legal guarantees of some kind w.r.t. your private keys in their contracts? Companies must find that sufficient? Or don't they? Perhaps it is something you pay extra for?
    – davidbak
    Commented Mar 25, 2021 at 3:29
  • A DDoS-only protection is always at layer 3 and 4. When the attacker is trying to overwhelm you with too many requests, which is what DDoS means, no proxy can afford to inspect them, but will simply throttle the connections and redirect the excess to a black hole via routing adjustments. I wouldn't consider layer 5-7 attacks in scope for “DDoS protection”.
    – Jan Hudec
    Commented Mar 25, 2021 at 8:25
  • @davidbak I have no idea, I don't use Cloudflare. Also, there are very different questions, not really related to the answer I gave. If you have questions of your own, you should consider posting a new question.
    – Teun Vink
    Commented Mar 25, 2021 at 9:14
  • 1
    Maybe I'm missing something, but if you're routing your traffic (at layer 3-4) to the CDN's IP addresses, then don't they already have everything they need to pass an ACME HTTP-01 challenge, and get certs issued for the domain?
    – James_pic
    Commented Mar 25, 2021 at 11:39
  • 1
    @James_pic Yes, and CloudFlare do exactly that. If it's the man-in-the-middle aspect that you're not comfortable with, though, then that's kind of beside the point.
    – IMSoP
    Commented Mar 25, 2021 at 11:58

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.

  • 2
    This is a good answer because it points the finger at the fact that DDoS protections above layer 4 can be easily done in-house (e.g. load balancing and rate-limiting). But it's important to stress out that services like Cloudflare cannot be substituted (for lower layer protection) because they are basically present in the backbone of the Internet and can stop attackers from overwhelming the links towards the load balancers at the source of the attack (while you can only stop it at the destination). Commented Mar 25, 2021 at 17:26

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.


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.

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:

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .