On 12 June 2013 23:00, William A. Rowe Jr. <wr...@rowe-clan.net> wrote: > On Wed, 12 Jun 2013 21:05:05 +0100 > Ben Laurie <b...@links.org> wrote: > >> 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). > > 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.
Yes. > I'm very interested in your short observation of how the OpenSSL > project is reacting, given this set of concerns and considerations? Its tricky for OpenSSL because compression is not a configurable option, its set (or not) by code, so we can't really change the default. The paranoid could build OpenSSL with OPENSSL_NO_COMP, but that might break applications.
