Defends against slow HTTP attacks.

[silence-coding]

I think hyper needs to add capabilities such as client_header_timeout and client_body_timeout to defend against slow attacks.

The Nginx defense method is as follows:
https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/#client_header_timeout

[mjbshaw]

Should #2675 have fully closed this? Seems like the second half of this issue is client_body_timeout, which is still unimplemented.

[seanmonstar]

I believe a user can handle a body timeout outside of a hyper, since you can add a timeout to any waiting on a body chunk. Is there something specific about it that hyper would need to do directly?

[mjbshaw]

Yeah, that should be sufficient. Sorry; when I read #2675 I noticed it said it partially addressed this issue, and that this issue's second half was client_body_timeout. But you're right. Thanks!

[DFINITYManu]

PR #2675 does not actually defend against slowloris attacks. From my comment there:

Valiant effort, but still there is no way to set a timeout for clients that connect only to send no data (by experimentation I discovered that the timeout does not fire if I just telnet into the TCP port and hang on there -- it only fires if I send the actual headers too late). Which means it's trivial to gum up a hyper server just by sending a lot of connections and nothing else.

What is needed is an actual "you sent no data over this period of time? close socket" timeout, and this should also be implemented for HTTP/2/3. There is a timeout field in https://recursion.wtf/embed-wasm/hyper/server/conn/struct.AddrIncoming.html but there is no way for the user to set it. Egads, the server socket is not closed until the client finally sends some data too late -- which is not how a massive open socket attack is going to go.

This issue ought to be reopened.

[jeromegn]

What is needed is an actual "you sent no data over this period of time? close socket" timeout, and this should also be implemented for HTTP/2/3

That's kind of hard, there are many things to take into account. For example:

• If you're proxying, then there's a race between the 2 idle timeouts if they're the same.
• The kernel buffers data that won't be immediately available in poll* functions (they'll receive a Poll::Pending even if there was actual data transmitted). So to figure it out, you also need to look at the tcpinfo struct you can get by doing a syscall and see how much data is "notsent". This adds blockage to normally non-blocking tasks. Even for a very short time, it can build up if you're handling a lot of connections.
• For HTTP2/3, multiple requests can happen on the same connection, at the same time. It could be possible to close a whole connection if any client request takes too long to send its headers, but would that be desirable? That would break all other ongoing HTTP requests for the same connection.

There is a timeout field in https://recursion.wtf/embed-wasm/hyper/server/conn/struct.AddrIncoming.html but there is no way for the user to set it.

That looks like the timeout for when accepting fails (usually due to "too many open files"). It's set to a sleep w/ a duration of 1 second when an error happens, when it has elapsed, it is removed.

Edit: I'm facing similar issues btw, I just thought I'd share my experience.