One of the things I noticed early on in my testing of Slowloris was that not every server reacted like you’d expect it to. Some gave database errors - I’m assuming because the database connections had different limits than the HTTP server. Whatever the reason, it only seemed vaguely interesting at first, from a fingerprinting perspective. The other issue is that to “see” the issue I had to basically hit a race condition by connecting to the webserver with my browser right in the split second as the sockets were being freed but before the database could recover. Not exactly the best way to go about things.
Then I started thinking about HTTP pipelining works in browsers, and also how HTTP sessions can send more than one request over a single socket. So imagine this. A server is under a Slowloris attack and either prior to the attack or by re-purposing one of the existing sockets to send something like the following:
GET / HTTP/1.1
User-Agent: Mozilla/4.0 …
Accept-Encoding: identity, *;q=0
On some web servers this will only send back a small amount of information because of the Range request header (the first ten bytes) which is awfully similar to a HEAD request, in terms of not wasting your bandwidth looking at something you don’t care about while you wait for the attack to ramp up. But more importantly the Keep-Alive will allow you to then send a second request a while later and then another one and so on…
What that means is that you can be the one person sitting at a very large table - you’ll have the website all to yourself. That’s because all the other sockets are tied up, so that no one else can use the site. With some re-programming Slowloris could be capable of that task, or a secondary program could be used to initiate and hold open a certain amount of sockets that you can use and re-use as you probe the site or use it in peace - because no one else will be on the site to bother you. It’s just another interesting side effect of a DoS that only denies the service to everyone - except you.