httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hartmut Keil <>
Subject Re: handling request splicing in case of server initiated renegotiation CVE-2009-3555
Date Tue, 17 Nov 2009 10:42:40 GMT
Hi Joe

Joe Orton wrote:
> On Mon, Nov 16, 2009 at 09:59:12PM +0100, Hartmut Keil wrote:
>> With the change described in
>> the buffer used in ssl_io_input_read(..) will be reset, and so the second request
>> 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.

The same situation occurs if stronger cipher suites are configured per location,
a wide used configuration pattern:


<Location / >
SSLCipherSuite HIGH:+AES:-MD5

> 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.

No, the proposed change would just affect to buffering-optimization in ssl_io_input_getline(...).
Pipelining HTTP over SSL does not required, to decrypt/buffer more data then needed.

> 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.

That is no solution since the data are already consumed from SSL, there
are no pending application_data.

> Regards, Joe


AdNovum Informatik AG
Hartmut Keil, Senior Software Engineer
Dipl. Physiker

Roentgenstrasse 22, CH-8005 Zurich
phone: +41 44 272 6111, fax: +41 44 272 6312

AdNovum Locations: Bern, Budapest, San Mateo, Zurich (HQ)

View raw message