Apache 2.2 - Change default for SSLCompression to off

[Petr Sumbera]

Hi guys,

shouldn't Apache 2.2 contain the same change which went for 2.4?

http://svn.apache.org/viewvc?view=revision&revision=1400962

Thanks,

Petr

looking for luv

[Jim Jagielski]

2 backport proposals looking 4 3vote-luv

 * mod_proxy_wstunnel: Backport (copy) websocket tunnel proxy submodule
 * skiplist: Add skiplist functionality
 

Re: asynch websockets tunnel

[Jim Jagielski]

I'm a big +1 on Eric folding this into trunk!

Re: asynch websockets tunnel

[Jim Jagielski]

re-looking at this, it would be nice if we could abstract
out the callback itself as simply "some event", where
the callback and the baton itself is self-contained
enuff to define what the event is... eg register_anevent_callback :)

Re: looking for luv

[Stefan Fritsch]

On Wednesday 12 June 2013, Jim Jagielski wrote:
> 2 backport proposals looking 4 3vote-luv

> * skiplist: Add skiplist functionality

There doesn't seem to be any user of the skiplist than 
register_timed_callback, and there doesn't seem to be any user of 
register_timed_callback besides mod_dialup.c. Is mod_dialup really 
that important? And is the inefficiency there a big problem? Maybe we 
could wait until there are more users of the API?

Re: Apache 2.2 - Change default for SSLCompression to off

[William A. Rowe Jr.]

On Wed, 12 Jun 2013 05:41:35 -0700 (PDT)
Petr Sumbera  wrote:

> Hi guys,
> 
> shouldn't Apache 2.2 contain the same change which went for 2.4?
> 
> http://svn.apache.org/viewvc?view=revision&revision=1400962

In principal, we do not change defaults in a released branch.

This was altered after 2.4.0 was released, so obviously that
principal was not followed.  Although there is no server vulnerability
addressed by this change, and although it is a flaw in implementations
(and far from all implementations) which that change addressed, it 
seems for consistency's sake that if the project caused this to change
in the release branch of 2.4 than it should change in the release
branch 2.2 as well.

However, the time to change this was obviously in 2.2.24.  It seems
that a lack of attention to detail by those committers let this change
escape scrutiny.

I believe the change is outside of the scope which server authors should
entertain, and it is up to the user agent authors to make an intelligent
choice knowing the risks and lack of risks in their agent implementation
but we aught to at least be consistent between stable release branches,
that is, if 2.4 is actually qualifies as a stable branch.

Perhaps this time, we entertain a proper vote rather than a pair of
devs electing to change defaults on a whim.  Stable branches are RTC
for a reason.

Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS

[Stefan Fritsch]

On Tuesday 11 June 2013, André Malo wrote:
> >trunk patch: http://svn.apache.org/r1491155
> >2.4.x patch: trunk patch works
> >nd: why would you do that in a stable branch?
> >
> > +  sf: Because it is only annoying and serves no purpose
> > anymore. If you +  want, we can make it a minor MMN bump
> > for adding a "new" API. +1: sf, covener
> >
> >-1: nd
> 
> Long discussions in STATUS are kinda tedious ;-)
> 
> Well, I think, such changes are what trunk is for. Why not simply
> leave  everything below as-is? Even more if it removes only an
> annoyance? Or is there a real technical reason I'm just not seeing
> right now?

It is a useful function. Disallowing it breaks ISO-C compliant code 
for no good reason. There has been a complaint by a module author. 
Allowing it does not use any memory because the function is already in 
libc. Working around the missing function requires additional code, 
which uses memory and may contain bugs. What more reasons do you need?

Or, is there a real technical reason to keep it broken in 2.4?

Re: svn commit: r1491700 - /httpd/httpd/trunk/modules/metadata/mod_mime_magic.c

[Christophe JAILLET]

Le 11/06/2013 09:41, jaillet...@apache.org a écrit :

Author: jailletc36
Date: Tue Jun 11 07:41:40 2013
New Revision: 1491700

URL:http://svn.apache.org/r1491700
Log:
According to comment in 'magic_rsl_add' and to the way 'magic_rsl_printf' 
manages its buffer, I think that this memory should be apr_pstrdup'ed.

This has been like that forever, but seems broken to me.

Untested.

Modified:
 httpd/httpd/trunk/modules/metadata/mod_mime_magic.c

Modified: httpd/httpd/trunk/modules/metadata/mod_mime_magic.c
URL:http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/metadata/mod_mime_magic.c?rev=1491700&r1=1491699&r2=1491700&view=diff
==
--- httpd/httpd/trunk/modules/metadata/mod_mime_magic.c (original)
+++ httpd/httpd/trunk/modules/metadata/mod_mime_magic.c Tue Jun 11 07:41:40 2013
@@ -606,7 +606,7 @@ static int magic_rsl_putchar(request_rec
  /* high overhead for 1 char - just hope they don't do this much */
  str[0] = c;
  str[1] = '\0';
-return magic_rsl_add(r, str);
+return magic_rsl_add(r, apr_pstrdup(r->pool, str));
  }
  
  /* allocate and copy a contiguous string from a result string list */



I made some testing with mod_mime_magic.
The change above has a real impact on output generated by the module.

I modified the magic file in order to see if I could reproduced PR21253 


My magic file has :
>
# XML eXtensible Markup Language, from Linus Walleij 
0   string  \6   string\7   string!DOCTYPE\ HTMLapplication2/xhtml+xml2
>8   stringDOCTYPE\ HTMLapplication3/xhtml+xml3
>9   stringOCTYPE\ HTMLapplication4/xhtml+xml4
>



Module unmodified gives :
$ wget -S --no-cache http://localhost/test.xx

--2013-06-12 20:44:11--  http://localhost/test.xx
Résolution de localhost (localhost)... 127.0.0.1
Connexion vers localhost (localhost)|127.0.0.1|:80... connecté.
requête HTTP transmise, en attente de la réponse...
  HTTP/1.1 200 OK
  Date: Wed, 12 Jun 2013 18:44:11 GMT
  Server: Apache/2.5.0-dev (Unix)
  Last-Modified: Wed, 12 Jun 2013 09:43:16 GMT
  ETag: "24a-4def1d7da1d1d"
  Accept-Ranges: bytes
  Content-Length: 586
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: 
application/xhtml+xml\aapplication2/xhtml+xml2\aapplication3/xhtml+xml3\aapplication4/xhtml+xml4 
<
Taille : 586 
[application/xhtml+xml\aapplication2/xhtml+xml2\aapplication3/xhtml+xml3\aapplication4/xhtml+xml4]

Enregistre : «test.xx.30»




Module modified with the strdup gives :
$ wget -S --no-cache http://localhost/test.xx

--2013-06-12 20:44:54--  http://localhost/test.xx
Résolution de localhost (localhost)... 127.0.0.1
Connexion vers localhost (localhost)|127.0.0.1|:80... connecté.
requête HTTP transmise, en attente de la réponse...
  HTTP/1.1 200 OK
  Date: Wed, 12 Jun 2013 18:44:54 GMT
  Server: Apache/2.5.0-dev (Unix)
  Last-Modified: Wed, 12 Jun 2013 09:43:16 GMT
  ETag: "24a-4def1d7da1d1d"
  Accept-Ranges: bytes
  Content-Length: 586
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: application/xhtml+xml <
  Content-Encoding: application2/xhtml+xml2 <
Taille : 586 [application/xhtml+xml]
Enregistre : «test.xx.31»


Before digging deeper in the module, I was wondering if someone was 
familiar with it and could give me some pointer about its internal.


Best regards,
CJ

Re: Apache 2.2 - Change default for SSLCompression to off

[Reindl Harald]

Am 12.06.2013 21:15, schrieb William A. Rowe Jr.:
> I believe the change is outside of the scope which server authors should
> entertain, and it is up to the user agent authors to make an intelligent
> choice knowing the risks and lack of risks in their agent implementation

yes and no

in fact if you are audited by 3rd partis of your customers
this will be detected and since this auditors are mostly
blind butchers you get a "fix it or shutdown"

from this point of view it should be disabled

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

where compression is a topic mod_deflate is used and do
compression on two layers is IMHO questionable





signature.asc
Description: OpenPGP digital signature

Re: Apache 2.2 - Change default for SSLCompression to off

[Stefan Fritsch]

On Wednesday 12 June 2013, William A. Rowe Jr. wrote:
> On Wed, 12 Jun 2013 05:41:35 -0700 (PDT)
> 
> Petr Sumbera  wrote:
> > Hi guys,
> > 
> > shouldn't Apache 2.2 contain the same change which went for 2.4?
> > 
> > http://svn.apache.org/viewvc?view=revision&revision=1400962
> 
> In principal, we do not change defaults in a released branch.

That's not true. It doesn't happen very often but it does happen.

> This was altered after 2.4.0 was released, so obviously that
> principal was not followed.  Although there is no server
> vulnerability addressed by this change, and although it is a flaw
> in implementations (and far from all implementations) which that

All web *browsers* that support compression are affected. Only non-
browser clients are not affected. Calling that "far from all" 
stretches things a bit.

> change addressed, it seems for consistency's sake that if the
> project caused this to change in the release branch of 2.4 than it
> should change in the release branch 2.2 as well.

I agree that it should be changed in 2.2, too. But it seems no one had 
time to do it.

> Perhaps this time, we entertain a proper vote rather than a pair of
> devs electing to change defaults on a whim.  Stable branches are
> RTC for a reason.

Huh? We had three devs voting for the backport. What more do you want?

Re: Apache 2.2 - Change default for SSLCompression to off

[Eric Covener]

>> Perhaps this time, we entertain a proper vote rather than a pair of
>> devs electing to change defaults on a whim.  Stable branches are
>> RTC for a reason.
>
> Huh? We had three devs voting for the backport. What more do you want?

FWIW I noticed in archive that sf was left off in the commit message
but was in the STATUS entry.

I would have been a fourth on concept (both needing the directive and
the default change) but either didn't see it in time or was gun shy of
mod_ssl/openssl (most of my exeperience is with a proprietary
alternative to both where I made the same change)

Re: Apache 2.2 - Change default for SSLCompression to off

[William A. Rowe Jr.]

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

Re: Apache 2.2 - Change default for SSLCompression to off

[William A. Rowe Jr.]

On Wed, 12 Jun 2013 21:27:18 +0200
Stefan Fritsch  wrote:

> On Wednesday 12 June 2013, William A. Rowe Jr. wrote:
> > On Wed, 12 Jun 2013 05:41:35 -0700 (PDT)
> > 
> > In principal, we do not change defaults in a released branch.
> 
> That's not true. It doesn't happen very often but it does happen.

Which is why I used the word principal.  When it happens, it is the
(legitimately necessary) exception.

> > This was altered after 2.4.0 was released, so obviously that
> > principal was not followed.  Although there is no server
> > vulnerability addressed by this change, and although it is a flaw
> > in implementations (and far from all implementations) which that
> 
> All web *browsers* that support compression are affected. Only non-
> browser clients are not affected. Calling that "far from all" 
> stretches things a bit.

You would be wrong, please see my other note.

> > change addressed, it seems for consistency's sake that if the
> > project caused this to change in the release branch of 2.4 than it
> > should change in the release branch 2.2 as well.
> 
> I agree that it should be changed in 2.2, too. But it seems no one
> had time to do it.

I plan to tag in sync with Jim's 2.4 tag, this would be a lovely time
to adopt such a change.

> > Perhaps this time, we entertain a proper vote rather than a pair of
> > devs electing to change defaults on a whim.  Stable branches are
> > RTC for a reason.
> 
> Huh? We had three devs voting for the backport. What more do you want?

I'd like an accurate svn commit message?  Is that a bit much to ask?
Or are we expected to troll through archives on every simple inquiry?

Re: Apache 2.2 - Change default for SSLCompression to off

[Reindl Harald]

Am 12.06.2013 21:49, schrieb William A. Rowe Jr.:
> On Wed, 12 Jun 2013 21:24:31 +0200
> Reindl Harald  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

https://www.ssllabs.com/ssltest/

check it with "OPENSSL_NO_DEFAULT_ZLIB=1" and without
this is what auditors do - period

it is completly irrelevant to guess which browsers are updated
and hpe that most users are up-to-date, well *my* browsers are
up-to-date but this *does not* help if you are looking at the
big picture and if there is a option enabled which can be a security
problem with zero benefit it should be disabled



signature.asc
Description: OpenPGP digital signature

Re: looking for luv

[Jim Jagielski]

On Wed, Jun 12, 2013 at 09:08:00PM +0200, Stefan Fritsch wrote:
> On Wednesday 12 June 2013, Jim Jagielski wrote:
> > 2 backport proposals looking 4 3vote-luv
> 
> > * skiplist: Add skiplist functionality
> 
> There doesn't seem to be any user of the skiplist than 
> register_timed_callback, and there doesn't seem to be any user of 
> register_timed_callback besides mod_dialup.c. Is mod_dialup really 
> that important? And is the inefficiency there a big problem? Maybe we 
> could wait until there are more users of the API?

They are useful.
-- 
===
   Jim Jagielski   [|]   j...@jagunet.com   [|]   http://www.jaguNET.com/
"Great is the guilt of an unnecessary war"  ~ John Adams

Re: Apache 2.2 - Change default for SSLCompression to off

[Reindl Harald]

Am 12.06.2013 21:52, schrieb William A. Rowe Jr.:
> On Wed, 12 Jun 2013 21:27:18 +0200
> Stefan Fritsch  wrote:
>> All web *browsers* that support compression are affected. Only non-
>> browser clients are not affected. Calling that "far from all" 
>> stretches things a bit.
> 
> You would be wrong, please see my other note

no, you have the naive impression that everybody out here
is using a browser with recent patches - this is *very*
far from the reality



signature.asc
Description: OpenPGP digital signature

Re: Apache 2.2 - Change default for SSLCompression to off

[Eric Covener]

On Wed, Jun 12, 2013 at 3:49 PM, William A. Rowe Jr.
 wrote:
> On Wed, 12 Jun 2013 21:24:31 +0200
> Reindl Harald  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.

Comment 5 seems to say it controls what the server is willing to
negotiate. What contrast were you drawing above?

https://bugzilla.redhat.com/show_bug.cgi?id=857051

Re: Apache 2.2 - Change default for SSLCompression to off

[Ben Laurie]

On 12 June 2013 20:49, William A. Rowe Jr.  wrote:
> On Wed, 12 Jun 2013 21:24:31 +0200
> Reindl Harald  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 :)

Re: Apache 2.2 - Change default for SSLCompression to off

[William A. Rowe Jr.]

On Wed, 12 Jun 2013 15:57:22 -0400
Eric Covener  wrote:

> On Wed, Jun 12, 2013 at 3:49 PM, William A. Rowe Jr.
>  wrote:
> > On Wed, 12 Jun 2013 21:24:31 +0200
> > Reindl Harald  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.
> 
> Comment 5 seems to say it controls what the server is willing to
> negotiate. What contrast were you drawing above?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=857051

It varies what the server elects based on the client's requested
compression state.

Comment 15 reiterates that these are two different switches.  The
RH patch avoids compelling the client to use compression, the httpd
patch prevents the use of compression.  Toggling the absolute behavior
in httpd rather than the preferred default behavior was probably not
appropriate for the stable branch, but what's done is done, and I won't
vote against backporting the 2.4 change to 2.2 (although I'm -0 on the
merits).

Re: looking for luv

[William A. Rowe Jr.]

On Wed, 12 Jun 2013 15:55:15 -0400
Jim Jagielski  wrote:

> On Wed, Jun 12, 2013 at 09:08:00PM +0200, Stefan Fritsch wrote:
> > On Wednesday 12 June 2013, Jim Jagielski wrote:
> > > 2 backport proposals looking 4 3vote-luv
> > 
> > > * skiplist: Add skiplist functionality
> > 
> > There doesn't seem to be any user of the skiplist than 
> > register_timed_callback, and there doesn't seem to be any user of 
> > register_timed_callback besides mod_dialup.c. Is mod_dialup really 
> > that important? And is the inefficiency there a big problem? Maybe
> > we could wait until there are more users of the API?
> 
> They are useful.

My question is not whether that feature is useful, rather whether this
belongs in httpd, or is a better candidate for apr?  A consolidated
patch of a 14-commit patchlist would be much easier to review :)

My question on mod_proxy_wstunnel is whether it can be considered
stable, or is (and should be documented as) experimental, in which
case I'd ask if $proxy_mods_enable is really the right default, or
whether the user should enable it explicity?

Re: Apache 2.2 - Change default for SSLCompression to off

[Stefan Fritsch]

On Wednesday 12 June 2013, William A. Rowe Jr. wrote:
> 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.

That's the browsers' broken "security model". I completely agree that 
this is a flaw on multiple levels, but browser vendors won't change 
it. They simply disabled compression to fix the CRIME issue.

> I'd like an accurate svn commit message?  Is that a bit much to
> ask? Or are we expected to troll through archives on every simple
> inquiry?

Noting the reviewers of a backport in the commit message is entirely 
optional, IMHO. If it isn't, it should be documented somewhere.

Re: looking for luv

[Jim Jagielski]

On Jun 12, 2013, at 4:24 PM, "William A. Rowe Jr."  wrote:

> 
> My question is not whether that feature is useful, rather whether this
> belongs in httpd, or is a better candidate for apr?

Either is fine, I guess. However, my plan is that the
eventopt stuff will eventually get backported to 2.4
and that requires skiplist and so we'll have an apr
dependency I don't think APR needs to be all-inclusive
and so adding stuff to httpd is OK (after all, APR started
off as a portability layer, not a "collection of all
useful things" :) )

>  A consolidated
> patch of a 14-commit patchlist would be much easier to review :)
> 


https://svn.apache.org/viewvc/httpd/httpd/trunk/server/skiplist.c?view=markup
https://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_skiplist.h?view=markup

How ez is that :)

Re: Apache 2.2 - Change default for SSLCompression to off

[William A. Rowe Jr.]

On Wed, 12 Jun 2013 21:05:05 +0100
Ben Laurie  wrote:

> On 12 June 2013 20:49, William A. Rowe Jr. 
> wrote:
> > On Wed, 12 Jun 2013 21:24:31 +0200
> > Reindl Harald  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?