On 12 June 2013 20:49, William A. Rowe Jr. <wr...@rowe-clan.net> wrote: > 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.
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 :)
