- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 9 Aug 2021 11:26:23 +0200
- To: Erik Aronesty <erik@q32.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Sat, Aug 07, 2021 at 06:13:05PM -0700, Erik Aronesty wrote: > 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. 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
Received on Monday, 9 August 2021 09:26:38 UTC