On Wed, 12 Jun 2013 21:05:05 +0100 Ben Laurie <[email protected]> wrote:
> On 12 June 2013 20:49, William A. Rowe Jr. <[email protected]> > wrote: > > On Wed, 12 Jun 2013 21:24:31 +0200 > > Reindl Harald <[email protected]> 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. I'm very interested in your short observation of how the OpenSSL project is reacting, given this set of concerns and considerations?
