2009/6/24 Kevin J Walters <kevin.walt...@morganstanley.com>: > >>>>>> "M" == Matthieu Estrade <mestr...@apache.org> writes: > > M> More granular timeout and maybe adaptative timeout is also IMHO a good > M> way to improve resistance to this kind of attack. > > The current 1.3, 2.0 and 2.2 documentation is in agreement too! > > I believe the ssl module also takes its timeout value from this > setting. It would be great if that was separately configurable too to > cater for those intent on doing partial ssl handshakes. > > > The TimeOut directive currently defines the amount of time Apache will wait > for three things: > > 1. The total amount of time it takes to receive a GET request. > 2. The amount of time between receipt of TCP packets on a POST or PUT > request. > 3. The amount of time between ACKs on transmissions of TCP packets in > responses. > > We plan on making these separately configurable at some point down the > road. The timer used to default to 1200 before 1.2, but has been > lowered to 300 which is still far more than necessary in most > situations. It is not set any lower by default because there may still > be odd places in the code where the timer is not reset when a packet > is sent.
>From what I understand, the server timeout value is also used to break deadlocks in mod_cgi due to POST data being greater than the UNIX socket buffer size and CGI script not reading POST data and then returning a response greater than the UNIX socket buffer size. In other words, CGI script blocks because Apache server child process isn't reading response. The Apache server child process is blocked still waiting for the CGI script to consume the response. The timeout value breaks the deadlock. In this context, making the timeout too small a value may have unintended consequences and affect how CGI scripts work, so a separate timeout for mod_cgi would be preferable. FWIW, the mod_cgid module doesn't appear to have this deadlock detection so in practice this issue could in itself be used as a denial of service vector when mod_cgid is used as it will completely lock up the Apache child server thread with no failsafe to unblock it. I have brought this issue up before on the list to get someone else to analyse mod_cgid code and see if what I see is correct or not, but no one seemed interested at the time, so took it that people didn't see it as important. It may not have been seen as such a big issue as on Linux systems the UNIX socket buffer size in the order of 220KB. On MacOS X though, the UNIX socket buffer size is only 8KB, so much easier to trigger. Unlike SendBufferSize and ReceiveBufferSize, there are no directives to override these buffer sizes for mod_cgi and mod_cgid. Graham