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 Wed, 12 Jun 2013 20:05:05 GMT
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).

>> where compression is a topic mod_deflate is used and do
>> compression on two layers is IMHO questionable
>
> Which is not the point, though :)

Mime
View raw message