Subject: Ddos prevention for ssl

From: Erik Aronesty <[email-masked]>
Date: Sat, 7 Aug 2021 18:13:05 -0700

SSL is increasingly required for website servers.

Well this is a good thing it does increase the burden on the server for
connections.

The amount of effort required to trigger key negotiations can be low
compared to the effort spent on the server.

An easy way to mitigate this would be for the server to require a small
proof of work.

A server can issue a nonce and a required proof level in order to proceed
with SSL negotiations.

Browsers could complete a proof of work within a millisecond or so.

In response to a denial of service attack the SSL layer could request an
increased proof of work for example.

Users of the website could then choose whether or not to comply based on
the difficulty and expected time of calculation.

A lightweight pow+authentication system like this could be a massive
deterrent for a denial of service attack.... effectively spreading the load
of the attack across all of the users of the site.

https://simulx.medium.com/1eccf3817e90

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 9 Aug 2021 11:26:23 +0200

> of the attack across all of the users of the site.

In general that's what is commonly done at the application level to
slow down clients. In practice it's not *that* hard to protect against
TLS floods, you just have to count the number of handshakes per source
address and block offending ones. It doesn't protect against CPU usage
spent on a new yet unverified address though.

But what you're proposing here (and in the other unrelated H2 thread that
you hijacked) needs to be discussed in the TLS group, not the HTTP group,
as it has nothing to do with HTTP at all.

Regards,
Willy

---

From: Erik Aronesty <[email-masked]>
Date: Mon, 9 Aug 2021 12:18:51 -0400

On Mon, Aug 9, 2021 at 5:26 AM Willy Tarreau <[email-masked]> wrot
> as it has nothing to do with HTTP at all.

oh, i for some reason i thought the tls was sort of "embedded" in the
new udp-based http2, and not a separate layer
will see what the tls groups think

---

From: Paul Vixie <[email-masked]>
Date: Mon, 9 Aug 2021 23:30:23 +0000

On Mon, Aug 09, 2021 at 11:26:23AM +0200, Willy Tarreau wrote:
> > ...
> address and block offending ones. ...

that mode of thought went out of fashion in 2009, when conficker had a
population of 11*10^6 infected clients. so even if it were (which it is not)
reasonable for every web server to count handshakes per source address, it
wouldn't be all that useful for even one web server to do so.

> as it has nothing to do with HTTP at all.

agreed as to this.

-- 
Paul Vixie

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 10 Aug 2021 06:25:29 +0200

> wouldn't be all that useful for even one web server to do so.

Quite the opposite, a proof of work has no effect on such a bot size,
while instead you can just fingerprint the handshake and reject those
that match above a threshold. The important thing here is counting
and reject outliers. Whether the key is a source address or a hash of
a handshake, the principle remains the same.

Willy

---

From: Erik Aronesty <[email-masked]>
Date: Tue, 10 Aug 2021 06:37:50 -0700

In my study a proof of work vastly improved resilience to a ddos with a
large number of seemingly valid handshake initializations

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 10 Aug 2021 15:53:59 +0200

> large number of seemingly valid handshake initializations

If you have a few clients which are forced to perform a lot of handshakes
each, sure. If you have 11M clients doing a single handshake each, as Paul
suggested, you still have to perform 11M handshakes once they validate the
challenge. That's why I said that when facing a large swarm of attackers
which is large enough to hurt you with a non-repetitive action, all you can
do is try to classify them based on their characteristics (e.g. signature).
And it's not easy at all. Sometimes even having to just handle the TCP
connection can be challenging.

Willy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Aug 2021 15:57:33 +0200

> new udp-based http2, and not a separate layer

...that's HTTP/3....

Best regards, Julian