httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Apache 2.2 - Change default for SSLCompression to off
Date Wed, 12 Jun 2013 19:49:42 GMT
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.

> 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