httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@links.org>
Subject Re: Apache 2.2 - Change default for SSLCompression to off
Date Thu, 13 Jun 2013 10:03:36 GMT
On 12 June 2013 23:00, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote:
> On Wed, 12 Jun 2013 21:05:05 +0100
> Ben Laurie <ben@links.org> wrote:
>
>> On 12 June 2013 20:49, William A. Rowe Jr. <wrowe@rowe-clan.net>
>> wrote:
>> > On Wed, 12 Jun 2013 21:24:31 +0200
>> > Reindl Harald <h.reindl@thelounge.net> wrote:
>> >>
>> >> well, on Redhat systems in "/etc/sysconfig/httpd" put the line
>> >> "OPENSSL_NO_DEFAULT_ZLIB=1" did disable it before httpd
>> >> offered a option, but IHMO any server software should
>> >> come with as much as secure defaults if they do not hurt
>> >
>> > Nothing special about httpd.  That is an OpenSSL flag (a patch
>> > still not adopted upstream AIUI) but it controls default behavior,
>> > not negotiated behavior.  I believe our patch disables compression
>> > altogether, which is a very different toggle, but I could be wrong.
>> >
>> > In fact, the patch's docs text is wrong on the face of it;
>> >
>> > "Enabling compression causes security issues in most setups (the
>> > so called +CRIME attack)"
>> >
>> > This is true of specific setups where the user agent simultaneously
>> > shares a compression dictionary between different client
>> > applications where one may be nefarious.  The vulnerability is to
>> > permit an untrusted agent (script) to share a single SSL and zlib
>> > session with a trusted/secured agent.  This is a flaw on multiple
>> > levels, not just limited to zlib compression packet sizes.
>> >
>> > What is useful about the RH patch is that it allows zlib to default
>> > to disabled behavior (but elect to be enabled) for ANY affected user
>> > agent/server.  What is further incorrect about **our claim** is that
>> > most user agents have been patched against this specific abuse.
>> > If our claim is to be believed, all services would appear
>> > vulnerable, not simply HTTP.
>> >
>> > CRIME-vulnerable browsers have already been patched.  By
>> > perpetuating stupid claims, we perpetrate stupidity for our users
>> > and in the media (who then proceeds to further perpetuate stupidity
>> > for our users).
>> >
>> > I think we should hold ourselves to a higher standard than alarmist
>> > and inaccurate user docs notes.  If we want to assign credit to a
>> > class of insecurities, we should cite primary sources (and let the
>> > security community publish meaningful analysis and guidance).
>> >
>> > "Enabling compression may introduce security issues in specific
>> > user-agents, particularly un-patched, insecure older browsers, and
>> > other badly designed user agents (an example, the so called +CRIME
>> > attack).  J Kelsey of Certicom described in "Compression and
>> > Information Leakage of Plain Text"
>> > [http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf]
>> > how a nefarious user agent or application may inject patterns when
>> > sharing an SSL session with an otherwise trusted agent or
>> > application and then inspect the actual compressed stream for
>> > variations, provided it has access to that raw transport stream."
>> >
>> > I think such a statement would be far more accurate, but I'll leave
>> > it to folks who are more expert than I to further wordsmith our
>> > claim.
>>
>> Actually, compression violates semantic security, and so, on general
>> principle, should be avoided unless you accept that risk (which is
>> hard to quantify, but sometimes large).
>
> Understood, so I interpret that you would be in favor of changing this
> sslcompression choice to disabled-by-default?  In that case, I'm very
> willing to toggle my vote from -0 to +0.

Yes.

> I'm very interested in your short observation of how the OpenSSL
> project is reacting, given this set of concerns and considerations?

Its tricky for OpenSSL because compression is not a configurable
option, its set (or not) by code, so we can't really change the
default. The paranoid could build OpenSSL with OPENSSL_NO_COMP, but
that might break applications.

Mime
View raw message