On Mon, Nov 16, 2009 at 09:59:12PM +0100, Hartmut Keil wrote: > With the change described in > https://issues.apache.org/bugzilla/show_bug.cgi?id=48204 > the buffer used in ssl_io_input_read(..) will be reset, and so the second > request of > the MITM will be dropped. > The first request will be executed, but since there is no Cookie from the > victim is the > less dangerous one.
Thanks for posting. So you are proposing that mod_ssl discards any decoded app-data message (i.e. HTTP traffic) *subsequent* to the data making up the request which triggered the renegotiation, but before the renegotiation occurs. This change would prevent a variant of the renegotiation prefix attack against a site which uses both client cert auth in a per-dir/location context, *and* HTTP-level authentication. It makes no difference to a vulnerable site relying only on client cert auth in per-dir/loc context; this would still be vulnerable. This would break HTTP pipelining over SSL (for affected configurations), and it might not fail gracefully - the server would appear to simply never receive the pipelined requests. I'm relucant to do that. A similar solution which detected pending buffered bytes after completing the handshake (SSL_pending(ssl) does this), and giving a hard failure (TLS level or HTTP level) might be better, but I haven't thought that through in detail. Regards, Joe
