On Wed, 12 Jun 2013 21:24:31 +0200 Reindl Harald <h.rei...@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 :)
