httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: handling request splicing in case of server initiated renegotiation CVE-2009-3555
Date Mon, 16 Nov 2009 22:19:03 GMT
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

Mime
View raw message