On 20/08/10 22:32, John Millikin wrote: > On Fri, Aug 20, 2010 at 12:52, Magnus Therning <mag...@therning.org> wrote: >> You don't need to send that much data, the current implementation of >> Enumerator uses hGet, which blocks, so just send the server a few bytes and >> it'll be sitting there waiting for input until it times out (if ever). >> Open a few hundred of those connections and you're likely to cause the >> server to run out of FDs. Of course this is already coded up in tools like >> slowloris[1] :-) > > Correct me if I'm wrong, but I'm pretty sure changing the implementation to > something non-blocking like hGetNonBlocking will not fix this. Hooking up an > iteratee to an enumerator which doesn't block will cause it to loop forever, > which is arguably worse than simply blocking. > > The best way I can think of to defeat a handle-exhaustion attack is to > enforce a timeout on HTTP header parsing, using something like > System.Timeout. This protects against slowloris, since requiring the > entire header to be parsed within some fixed small period of time > prevents the socket from being held open via slowly-trickled headers.
Indeed. In many protocols it would force the attacker to send well-formed requests though. I think this is true for many text-based protocols like HTTP. The looping can be handled effectively through hWaitForInput. There are also other reasons for doing non-blocking IO, not least that it makes developing and manual testing a lot nicer. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
