Reading between the lines; changelog

["William A. Rowe Jr." <wr...@rowe-clan.net>]

Anyone looking at the changelog should be terrified of adopting 2.2.15; I'm going
to modify it thusly (please correct attributions if needed?);

  *) SECURITY: CVE-2009-3555 (cve.mitre.org)
     mod_ssl: Comprehensive fix of the TLS renegotiation prefix injection
     attack when compiled against OpenSSL version 0.9.8m or later. Introduces
     the 'SSLInsecureRenegotiation' directive, which allows unsafe legacy
     renegotiation with clients which do not yet support the secure
     renegotiation protocol.  [Joe Orton]

  *) SECURITY: CVE-2009-3555 (cve.mitre.org)
     mod_ssl: A partial fix for the TLS renegotiation prefix injection attack
     for OpenSSL versions prior to 0.9.8l; reject any client-initiated
     renegotiations. Forcibly disable keepalive for the connection if there
     is any buffered data readable. Any configuration which requires
     renegotiation for per-directory/location access control is still
     vulnerable, unless using openssl 0.9.8l or later.
     [Joe Orton, Ruediger Pluem, Hartmut Keil <Hartmut.Keil adnovum.ch>]

WDYT?

Re: Reading between the lines; changelog

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On 3/5/2010 4:13 PM, Jeff Trawick wrote:
> On Fri, Mar 5, 2010 at 4:55 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>> Anyone looking at the changelog should be terrified of adopting 2.2.15; I'm going
>> to modify it thusly (please correct attributions if needed?);
>>
>>  *) SECURITY: CVE-2009-3555 (cve.mitre.org)
>>     mod_ssl: Comprehensive fix of the TLS renegotiation prefix injection
>>     attack when compiled against OpenSSL version 0.9.8m or later.
> 
> I see what you mean about potential fear; OTOH, maybe "comprehensive
> fix" is misleading too.  Joe mentioned adding something to the FAQ
> about the issue.  Perhaps that's the only solution.

I will solve through the CHANGES, as well, to at least calm fears that there is only
half a solution in 2.2.15.  (Well, there is only half a solution, the other half is
in openssl :-)

Here is some slight rewording; I don't believe comprehensive is misleading at all,
the exposure isn't mitigated, it is eliminated [until they are foolish enough to
re-enable SSLInsecureRenegotiation].  We also can hardly assume most credit.  So I'd
suggest this phrasing;

     mod_ssl: Comprehensive fix of the TLS renegotiation prefix injection
     attack when compiled against OpenSSL version 0.9.8m or later. Introduces
     the 'SSLInsecureRenegotiation' directive to reopen this vulnerability
     and offer unsafe legacy renegotiation with clients which do not yet
     support the secure renegotiation protocol.  [Joe Orton, and the OpenSSL Team]

Re: Reading between the lines; changelog

[Jeff Trawick <tr...@gmail.com>]

On Fri, Mar 5, 2010 at 4:55 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> Anyone looking at the changelog should be terrified of adopting 2.2.15; I'm going
> to modify it thusly (please correct attributions if needed?);
>
>  *) SECURITY: CVE-2009-3555 (cve.mitre.org)
>     mod_ssl: Comprehensive fix of the TLS renegotiation prefix injection
>     attack when compiled against OpenSSL version 0.9.8m or later.

I see what you mean about potential fear; OTOH, maybe "comprehensive
fix" is misleading too.  Joe mentioned adding something to the FAQ
about the issue.  Perhaps that's the only solution.

I feel like we should convey "we've done the best we can as far as we
know; you should definitely use 2.2.15 and 0.9.8m; you'll be fine if
you don't require renegotiation with old/existing clients, but you're
still screwed if you require renegotiation with old/existing clients"
;)

Here's a summary I sent someone recently.

OpenSSL

0.9.8k and before
all legacy renegotiation is allowed
secure renegotiation not implemented

0.9.8l
legacy renegotiation is allowed only if an API call is made; this API
call isn't suitable for use by mod_ssl, so mod_ssl doesn't exploit it
secure renegotiation not implemented

0.9.8m and later
legacy renegotiation is allowed only if an API call is made; this
release has a new API suitable for use by mod_ssl
secure renegotiation is implemented

mod_ssl in general

client-initiated renegotiation is never needed
server-initiated renegotiation is required for some optional mod_ssl
configurations; if the admin needs to disable server-initiated
renegotiation, they have to consider if their configuration is
impacted and how to mitigate

mod_ssl starting in httpd 2.2.15

* client-initiated renegotiation, legacy or new, is always disabled,
regardless of the level of OpenSSL
* one possible MITM attack against server-initiated legacy
renegotiation is protected against, regardless of the level of
OpenSSL; this is not a complete solution though
* when used with OpenSSL 0.9.8m or later:
** mod_ssl sets a request note as well as a request "envvar" to
indicate whether the client supports secure renegotiation
** the new renegotiation protocol is available with no config changes
** legacy renegotiation is disabled by default
** a new directive is provided to enable legacy renegotiation if that
is required because of the client base

Clients

Clients still need to be upgraded to support the new renegotiation protocol.