0

This question is quite general as I want to understand the (security) benefits of a 'timeout' in general.

For our Nginx proxy-server, we have been using HTTP/S timeouts where we came across the issue were the Nginx server returned a time-out. Now, we have solved this by simply increasing the Nginx time-out. We keep upscaling the timeout, may it be for a specific endpoint, it seems we keep pushing an underlying problem. We see this problem again and again where I asked the question: Why do we even want to have timeouts?

Thinking about some malicious attempts, like sending a bulk of load to the server, if Nginx gives a timeout (or any 'timeout manager') the server would still be processing the data.

So, why would we use server timeouts and what would be a better way to solve the issues for reaching the timeout cap every time? Would be paradigm like WebSocket, SSE or (Long-)Polling resolve this?

1
  • Basically timeouts release resources that have no activity on them, in your case looks like is timeouts related to HTTPS/TCP connections. – camp0 Apr 24 '20 at 11:30
5

Timeouts are necessary because the internet is unreliable.

We like to think of the internet as based on "connections", but that's not actually true. It's based on individual packets, which are received discretely and independently of each other.

In simple terms, when the server wants to send or receive data, the server usually can't send all the data in one packet. Instead, the data is chopped up and sent in individual packets.

In the best case scenario, the client would receive each packet, and then send an acknowledgement back that the packet was received. But what if the client never responds? This can have various reasons such as bad internet connectivity (think mobile internet), a crashed application, someone tripping over a cable, the bomb detonating on bomb site B, etc...

The server is blissfully unaware of the fate of the client. All the server knows is that no acknowledgement was received, and assumes the packet was lost, so the server sends the packet again. If the reason why the packet was received was temporary, then the client will receive the resent packet without problems and the communication will continue. If the reason is more permanent, you don't want the server to keep sending packets needlessly if the client would never answer.

As a result, the server at some point "times out", assumes the client is gone and frees the resources it has allocated for the transmission.

Why is this relevant for security?

The Slowloris Attack abuses the way how many web servers treat incoming connections. By sending requests veeeeeeeeryyyyy slooooooowly, the web server never quite times out, but instead has to keep allocating resources to keep the incoming request in memory.

The solution, or rather, mitigation to these attacks is limiting how slow a client is allowed to be. By sending them a timeout if the request took too long to complete you effectively set an upper bound on how effective such an attack can be.

What about clients just sending lots of data?

You can configure the server to set a maximum request size. Anything larger than this would be disregarded and the connection would be reset mid-transfer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.