Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of jorton@redhat.com designates
 209.132.183.28 as permitted sender)
Date: Mon, 16 Nov 2009 22:19:03 +0000
From: Joe Orton <jorton@redhat.com>
To: Hartmut Keil <Hartmut.Keil@adnovum.ch>
Cc: dev@httpd.apache.org
Subject: Re: handling request splicing in case of server initiated
	renegotiation CVE-2009-3555
Message-ID: <20091116221903.GB18036@redhat.com>
Mail-Followup-To: Hartmut Keil <Hartmut.Keil@adnovum.ch>,
	dev@httpd.apache.org
References: <4B01BD20.1060300@adnovum.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4B01BD20.1060300@adnovum.ch>
User-Agent: Mutt/1.5.19 (2009-01-05)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
 Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
 Matt Parson (USA), Charlie Peters (USA)

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