Re: expose SSL_SHARED_CIPHERs from SSL/TLS

[Dirk-Willem van Gulik]

> On 6 Mar 2023, at 13:32, Ruediger Pluem  wrote:
> 
> 
> 
> On 3/6/23 12:35 PM, Dirk-Willem van Gulik wrote:
>> I was cleaning up some of our private code - and came across the patch below 
>> - exposing the SHARED_CHIPHERs.
>> 
>> We scratch this itch in a few places to help force (or prevent) the forcing 
>> of a protocol upgrade from application land.
>> 
>> No idea how common that is - any reason not to submit this as a suggestion 
>> for some future httpd version ?
> 
> If you provide some documentation for the var, go for it :-)

Draft against trunk below. As far as I could see mod_ssl.xml was the most 
sensible place to document this. 

Updated the SSL_CIPHER a little to clarify the relation between the two.

Dw

Index: docs/manual/mod/mod_ssl.xml
===
--- docs/manual/mod/mod_ssl.xml (revision 1908122)
+++ docs/manual/mod/mod_ssl.xml (working copy)
@@ -66,7 +66,8 @@
 SSL_SESSION_IDstring
The hex-encoded SSL session id
 SSL_SESSION_RESUMED   string
Initial or Resumed SSL Session.  Note: multiple requests may be served over 
the same (Initial or Resumed) SSL session if HTTP KeepAlive is in use
 SSL_SECURE_RENEG  string
true if secure renegotiation is supported, else 
false
-SSL_CIPHERstring
The cipher specification name
+SSL_SHARED_CIPHERSstring
Colon separated list of shared chiper (i.e. possible chipers that are 
present on both server and with the client))
+SSL_CIPHERstring
The name of the selected cipher
 SSL_CIPHER_EXPORT string
true if cipher is an export cipher
 SSL_CIPHER_USEKEYSIZE number
Number of cipher bits (actually used)
 SSL_CIPHER_ALGKEYSIZE number
Number of cipher bits (possible)
Index: modules/ssl/ssl_engine_kernel.c
===
--- modules/ssl/ssl_engine_kernel.c (revision 1908122)
+++ modules/ssl/ssl_engine_kernel.c (working copy)
@@ -1532,6 +1532,7 @@
 "SSL_SERVER_A_SIG",
 "SSL_SESSION_ID",
 "SSL_SESSION_RESUMED",
+"SSL_SHARED_CIPHERS",
 #ifdef HAVE_SRP
 "SSL_SRP_USER",
 "SSL_SRP_USERINFO",
Index: modules/ssl/ssl_engine_vars.c
===
--- modules/ssl/ssl_engine_vars.c (revision 1908122)
+++ modules/ssl/ssl_engine_vars.c (working copy)
@@ -506,6 +506,11 @@
 else if (ssl != NULL && strcEQ(var, "COMPRESS_METHOD")) {
 result = ssl_var_lookup_ssl_compress_meth(ssl);
 }
+else if (ssl != NULL && strcEQ(var, "SHARED_CIPHERS")) {
+char buf[ 1024 * 16 ];
+if (SSL_get_shared_ciphers(ssl,buf,sizeof(buf)))
+   result = apr_pstrdup(p,buf);
+}
 #ifdef HAVE_TLSEXT
 else if (ssl != NULL && strcEQ(var, "TLS_SNI")) {
 result = apr_pstrdup(p, SSL_get_servername(ssl,

expose SSL_SHARED_CIPHERs from SSL/TLS

[Dirk-Willem van Gulik]

I was cleaning up some of our private code - and came across the patch below - 
exposing the SHARED_CHIPHERs.

We scratch this itch in a few places to help force (or prevent) the forcing of 
a protocol upgrade from application land.

No idea how common that is - any reason not to submit this as a suggestion for 
some future httpd version ?

Dw


Index: modules/ssl/ssl_engine_vars.c
===
--- modules/ssl/ssl_engine_vars.c   (revision 620141)
+++ modules/ssl/ssl_engine_vars.c   (working copy)
@@ -320,6 +320,11 @@
 else if (ssl != NULL && strcEQ(var, "COMPRESS_METHOD")) {
 result = ssl_var_lookup_ssl_compress_meth(ssl);
 }
+else if (ssl != NULL && strcEQ(var, "SHARED_CIPHERS")) {
+   char buf[ 1024 * 16 ];
+   if (SSL_get_shared_ciphers(ssl,buf,sizeof(buf)))  +   
result = apr_pstrdup(p,buf);
+}
 #ifndef OPENSSL_NO_TLSEXT
 else if (ssl != NULL && strcEQ(var, "TLS_SNI")) {
 result = apr_pstrdup(p, SSL_get_servername(ssl,
Index: modules/ssl/ssl_engine_kernel.c
===
--- modules/ssl/ssl_engine_kernel.c (revision 620141)
+++ modules/ssl/ssl_engine_kernel.c (working copy)
@@ -1067,6 +1067,7 @@
 "SSL_SERVER_A_KEY",
 "SSL_SERVER_A_SIG",
 "SSL_SESSION_ID",
+"SSL_SHARED_CIPHERS",
 NULL
 };


and config
SSLSessionCache None
SSLSessionCacheTimeout  1
...
EOM

Extra bucket brigade with just an EOS on an input filter at the end.

[Dirk-Willem van Gulik]

In some code 
(https://source.redwax.eu/svn/redwax/rs/mod_cms_verify/trunk/mod_cms_verify.c) 
I have in input filter (that checks a PKCS#7 signature before passing the 
payload on to a proxy/cgi-script, etc).

I am testing this with:

echo  "field1=foo&field2=bar” |\
openssl cms -sign -signer /tmp/sign.cert -outform DER -stream  
|\
 curl --data-binary @- - http://127.0.0.1:8080/show.cgi

Works well.

But I am seeing after all this going well an extra bucket brigade being passed; 
with 0 bytes. And I’d like to understand why.

Code is roughly 
((https://source.redwax.eu/svn/redwax/rs/mod_cms_verify/trunk/mod_cms_verify.c 
for the real McCoy):

  static apr_status_t _input_filter(ap_filter_t * f,  apr_bucket_brigade * 
bbout, ….
  {
verify_config_rec *conf = ap_get_module_config(r->per_dir_config, 
&cms_verify_module);
request_rec *r = f->r;

bb = apr_brigade_create(r->pool, r->connection->bucket_alloc);

if (state == NULL)  {
setup some state..
state->pbb_tmp = apr_brigade_create(r->pool, c->bucket_alloc);
….
}

if (APR_BRIGADE_EMPTY(state->pbb_tmp)) {
rv = ap_get_brigade(f->next, state->pbb_tmp, eMode, eBlock, nBytes);
if (eMode == AP_MODE_EATCRLF || rv != APR_SUCCESS)
return rv;
}

while (!APR_BRIGADE_EMPTY(state->pbb_tmp)) {
apr_bucket *pbkt_in = APR_BRIGADE_FIRST(state->pbb_tmp);
const char *data;
apr_size_t len;

if (APR_BUCKET_IS_EOS(pbkt_in)) {
apr_bucket *pbkt_out = validate()..

if (pbkt_out is valid) 
APR_BRIGADE_INSERT_TAIL(bbout, pbkt_out);

APR_BRIGADE_INSERT_TAIL(bbout, 
apr_bucket_eos_create(r->connection->bucket_alloc));
APR_BUCKET_REMOVE(pbkt_in);
break;
}

rv = apr_bucket_read(pbkt_in, &data, &len, eBlock);
if (rv != APR_SUCCESS)
return rv;

… add len bytes to a buffer

apr_bucket_delete(pbkt_in);
};
return APR_SUCCESS;
   }

And mostly taken from mod_example.

What I am seeing is a first brigade with the POST content; with a terminating 
EOF. The bbout data makes it to the CGI script or (reverse) proxy. 

But I am then getting a second _input_filter call with a second brigade of just 
an EOS packet.

What causes that ? Or am I not running through the brigade properly ?

Dw

Re: child exit on self-proxy

[Dirk-Willem van Gulik]

On 14 Jul 2021, at 23:47, Yann Ylavic  wrote:
> On Wed, Jul 14, 2021 at 3:42 PM Yann Ylavic  wrote:
>> 
>> On Tue, Jul 13, 2021 at 4:16 PM Stefan Eissing
>>  wrote:
>>> 
>>> In Yann's v3 of the patch, it triggers only when I stop the server while 
>>> the test case is ongoing,
>> 
>> OK thanks, I have a new v6 which should address this and also still
>> call pre_close hooks in any case.
>> The patch is a bit "verbose" (some cosmetics/comments changes that
>> helped my workflow, sorry about that) but in the end I think it's
>> simpler to maintain (as Eric asked?) which may be worth it..
> 
> I have staged this a bit in https://github.com/apache/httpd/pull/208

Lovely - well done - this fixes things on our end.

Dw

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

[Dirk-Willem van Gulik]

Thank you so much for finding is! 

This one has been plaguing us for quite a bit - and we where totally looking in 
the wrong place.

Dw.

> On 22 Mar 2020, at 13:12, gbec...@apache.org wrote:
> 
> Author: gbechis
> Date: Sun Mar 22 12:12:21 2020
> New Revision: 1875516
> 
> URL: http://svn.apache.org/viewvc?rev=1875516&view=rev
> Log:
> propose mod_ssl fix [skip ci]
> 
> Modified:
>httpd/httpd/branches/2.4.x/STATUS
> 
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1875516&r1=1875515&r2=1875516&view=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Sun Mar 22 12:12:21 2020
> @@ -156,6 +156,13 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>  months/years without any action item :)
>  ylavic: will look at it ASAP..
> 
> +  *) mod_ssl: Fix memory leak of OCSP stapling response.
> +  The OCSP_RESPONSE is either ignored or serialized 
> (i2d_OCSP_RESPONSE) in the
> +  TLS response/handshake extension, so it must be freed.
> + trunk patch: http://svn.apache.org/r1874577
> + 2.4.x patch: svn merge -c 1874577 ^/httpd/httpd/trunk .
> + +1: gbechis
> +
> PATCHES/ISSUES THAT ARE BEING WORKED
>   [ New entries should be added at the START of the list ]
> 
> 
> 

Re: Netcraft

[Dirk-Willem van Gulik]

Jim,

On 21 Feb 2020, at 13:20, Jim Jagielski  wrote:

> Wow. Was Netcraft actually somewhat kind to Apache httpd? They actually 
> admitted some areas where httpd is doing better, and still does better, 
> market-share wise, than nginx.


They are very kind (and professional) people. And the pub in Bath is great (and 
it is one of the most lovely cities in England too) - I am sure they would not 
mind showing you around.

Dw.

Re: "Most Popular Web Server?"

[Dirk-Willem van Gulik]

On 19 Apr 2018, at 12:09, Graham Leggett  wrote:
> On 18 Apr 2018, at 10:46 PM, Mark Blackman  wrote:
> 
>> Is most popular the right thing to aim for? I would advise continuing to 
>> trade on Apache’s current strengths (versatility and documentation for me 
>> and relative stability) and let the chips fall where they may. It’s an open 
>> source project with a massive first-mover advantage and no investors to 
>> please. Just do the right thing, stay visible and the rest will sort itself 
>> out.
> 
> I agree strongly with this. I took a look at nginx and gave it a fair 
> evaluation, then I discovered this:
> ..
> "Anything else may possibly cause unpredictable behaviour, including 
> potential SIGSEGV.”
> 
> Both this document and the idea that SIGSEGV would remain unfixed would never 
> fly at Apache. Nginx suffers the problem in that product managers have to 
> trade off the pressure of new features for the marketing people over the need 
> to fix problems they already have. This isn’t sustainable for them.
..
> The strength of httpd is that it is a tank - it just keeps going and going. 
> You can deploy it and completely forget about it, it just works. This frees 
> up our users to focus their attention on doing whatever it is they want to do.

Large crude oil tankers and formula 1 racing cars are both things that can go 
from A to B. Yet they have different qualities. 

Perhaps we need to emphasise this a bit more - that there is room for different 
things in this market. 

I’ve found the same in production - nginx can be wonderfully fast in certain 
settings - but can also be a relatively fragile and finicky beast best ran in 
serious loadbalancing/failover.

Dw.

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

[Dirk-Willem van Gulik]

> On 7 Feb 2018, at 16:24, Graham Leggett  wrote:
> 
> On 07 Feb 2018, at 5:18 PM, Graham Leggett  wrote:
> 
>> Looking back through the archives, looks like that backport was already 
>> accepted:
>> 
>> http://svn.apache.org/viewvc?view=revision&revision=1634520
> 
> Hmmm… it’s actually only solved the URL too long problem, the hostname too 
> long problem is still a fatal error:
> 
> ptr = apr_uri_unparse(p, &uri, APR_URI_UNP_REVEALPASSWORD);
> if (PROXY_STRNCPY(wshared->name, ptr) != APR_SUCCESS) {
> ap_log_error(APLOG_MARK, APLOG_ERR, 0, ap_server_conf, APLOGNO(02808)
> "Alert! worker name (%s) too long; truncated to: %s", ptr, 
> wshared->name
> );
> }
> if (PROXY_STRNCPY(wshared->scheme, uri.scheme) != APR_SUCCESS) {
> return apr_psprintf(p, "worker scheme (%s) too long", uri.scheme);
> }
> if (PROXY_STRNCPY(wshared->hostname, uri.hostname) != APR_SUCCESS) {
> return apr_psprintf(p, "worker hostname (%s) too long", uri.hostname);
> }
> 
> Would this break if we did the same warning on hostname that’s done on the 
> full URL?

Not sure how this broke on your end - but the cases where I had it break on me 
in production where all cases where things were generated and dynamically 
registered with some sort of ``service-zone-status-etc-’’ thing:


casemo-apiservice-backend-frankfurt-production-W0091-2a01-4f80-0201--32e6---0002

so chopping of the end is a bit painful.

Dw.


signature.asc
Description: Message signed with OpenPGP

Re: New ServerUID directive

[Dirk-Willem van Gulik]

> On 2 Feb 2018, at 15:44, Stefan Eissing  wrote:
> 
> 
> 
>> Am 02.02.2018 um 15:42 schrieb Yann Ylavic :
>> 
>> On Fri, Feb 2, 2018 at 3:25 PM, Plüm, Rüdiger, Vodafone Group
>>  wrote:>
>>> 
 -Ursprüngliche Nachricht- Von: Jim Jagielski
 [mailto:j...@jagunet.com] Gesendet: Freitag, 2. Februar 2018 15:15
 An: httpd  Betreff: Re: New ServerUID
 directive
 
 Why? If it is designed to not change between restarts then there
 are much easier ways to be unique, which it kinda already is,
 considering the actual structs being used.
>> 
>> I don't know what "easier ways" you are thinking about, the one
>> proposed here is not that complicated IMO.
>> In any case the method we are currently using in mod_proxy_lb *is*
>> changing accross restarts, mainly because of the line number.
>> What if you add/remove a line before the ?
>> At least for graceful restarts, I think it shall not change, SHMs
>> should be reused.
> 
> Is it a hash across the config record of a server what would give
> the desired behaviour?

We have several internal modules which sort of need this. In each case we 
generate a  sha256 and a UUID based on the FQDN or IP address and the (first) 
port number it listens on. 

And we then log this with ‘info’ during startup; thus allowing an admin to at 
some later point add a ServerUUID to the list of ServerName, ServerAdmin, etc. 
as he or she sees fit.

As in practice - we found that in the few times when you need to change that 
UUID - you are in effect doing that as part of switching to a new origin server 
or something like that at protocol level with respect to things like locks, 
caches and other short-transactions/connection RESTy things surviving stuff.

That said - having this in the core and being able to routinely seed this extra 
into things like cookies is goodness. We do that a lot now - and it helps with 
simplifying compliance a lot.

Dw.

Re: SSL and Usability and Safety

[Dirk-Willem van Gulik]

> On 3 May 2017, at 15:14, Issac Goldstand  wrote:
> 
> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
>> 
>>> On 3 May 2017, at 14:53, Issac Goldstand >> <mailto:mar...@beamartyr.net>> wrote:
>>> 
>>> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>>>> On 3 May 2017, at 10:03, Issac Goldstand >>> <mailto:mar...@beamartyr.net>> wrote:
>>>>> 
>>>>> +1 on the idea
>>>>> 
>>>>> So far I'm -0 about all of the proposed implementations for 2 reasons:
>>>>> 
>>>>> 1) Mr and Mrs normal (whom are our primary customers in the original
>>>>> proposal) usually download Apache from their distro or some other
>>>>> binary.  Their Apache sources are usually not up-to-date, and in the
>>>>> scenario that a new vulnerability is found it would take ages to
>>>>> propagate to them, anyway
>>>>> 
>>>>> 2) For those users who are comfortable building their own source, they
>>>> ….
>>>> 
>>>> So how about ‘us’ taking the lead here. 
>>> 
>>> That's the part I was always +1 on :)
>>> 
>>>> We, here, simply define ‘one’ setting as the industry best standard -
>>>> which roughly corresponds to what ssllabs their test would get you an
>>>> A+ and that pretty much meets or exceeds the various NIST et.al.
>>>> recommendations for key lengths for the next 5 years. 
>>> 
>>> The problem is, that we don't know what's going to be good going forward
>>> five years, and IMHO the best standards are shaped at least equally by
>>> removing "negatives" often because of high-risk vulnerabilities, as by
>>> adding new "positives" due to new available ciphers/tools
>> 
>> Right - so I think there are two things
>> 
>> 1)the general advice of NIST et.al. - summarized nicely at:
>> 
>> https://www.keylength.com
>> 
>> which tells us what our `best acceptable’ choises are in any release
>> going out and their likely vailidy for the next 5 years.
>> 
>> And then there is our response to things that become known; such as
>> vulnerability - for which we have a proven update proces that is
>> dovetailed by us sending mail to announce, the security mailing lists
>> and similar outreach.
> 
> Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
> and Mrs normal aren't on the mailing list of most pieces of software,
> even if they use them.
> 
> If we truly want to cater to them (and by doing so, do our part in
> advocating a safer and more secure internet) then I maintain that we'd
> need to do better.

Right - but then we are in the land of automatic updates; binary package 
fetching and what not ? Or at the very least - pulling down a file over the 
internet from ‘us’ that is sufficiently protected yet robust, etc ?

That is a whole new land?

Dw.

Re: SSL and Usability and Safety

[Dirk-Willem van Gulik]

> On 3 May 2017, at 14:53, Issac Goldstand  wrote:
> 
> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>> On 3 May 2017, at 10:03, Issac Goldstand  wrote:
>>> 
>>> +1 on the idea
>>> 
>>> So far I'm -0 about all of the proposed implementations for 2 reasons:
>>> 
>>> 1) Mr and Mrs normal (whom are our primary customers in the original
>>> proposal) usually download Apache from their distro or some other
>>> binary.  Their Apache sources are usually not up-to-date, and in the
>>> scenario that a new vulnerability is found it would take ages to
>>> propagate to them, anyway
>>> 
>>> 2) For those users who are comfortable building their own source, they
>> ….
>> 
>> So how about ‘us’ taking the lead here. 
> 
> That's the part I was always +1 on :)
> 
>> We, here, simply define ‘one’ setting as the industry best standard - which 
>> roughly corresponds to what ssllabs their test would get you an A+ and that 
>> pretty much meets or exceeds the various NIST et.al. recommendations for key 
>> lengths for the next 5 years. 
> 
> The problem is, that we don't know what's going to be good going forward
> five years, and IMHO the best standards are shaped at least equally by
> removing "negatives" often because of high-risk vulnerabilities, as by
> adding new "positives" due to new available ciphers/tools

Right - so I think there are two things

1)  the general advice of NIST et.al. - summarized nicely at:

https://www.keylength.com

which tells us what our `best acceptable’ choises are in any release going out 
and their likely vailidy for the next 5 years.

And then there is our response to things that become known; such as 
vulnerability - for which we have a proven update proces that is dovetailed by 
us sending mail to announce, the security mailing lists and similar outreach.

>> We’d wrap this into a simple policy document. Promise ourselfves that we’d 
>> check this every release and at least once a year review it. And have a 
>> small list of the versions currently meeting or exceeding our policy.
>> 
>> And this is the setting you get when you do ‘SSLEngine On’.
> 
> To me this doesn't address the time lags between shipping it in source,
> and it getting implemented on the machine.  I don't see it as superior
> in any way to, say, putting the recommended settings in the online docs
> and updating that from time to time - moreso when that update is in
> response to a new vulnerability.

I think we should make sure that 1) any release that goes out meets or exceeds 
industry practice (e.g. the BSI 2017 recommendation up to 2022); and 2) that we 
keep a list of versions that are still `current’ enough; and that accomodates 
what we since their release learned. Typically meaning - update to version X.Y.

Dw

Re: SSL Policy Definitions

[Dirk-Willem van Gulik]

> On 3 May 2017, at 14:09, Graham Leggett  wrote:
> 
> On 03 May 2017, at 2:01 PM, Stefan Eissing  
> wrote:
> 
>> We seem to all agree that a definition in code alone will not be good 
>> enough. People need to be able to see what is actually in effect.
> 
> I think we’re overthinking this.
> 
> We only need to document the settings that SSLSecurityLevel has clearly in 
> our docs, and make sure that "httpd -L” prints out the exact details so no 
> user need ever get confused.
> 
>> If we let users define their own classes, it could look like this:
> 
> Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal.

Agreed. If our default is simply ‘industry best practice’ (i.e. what we say it 
is*) — then Normal will be the new black.

And everyone else is still in the same boat - i.e. having to specify it just 
like they do today.

All that requires it to make the defaults sane.

Dw.

*: exceed NIST and https://www.keylength.com/  for 
5+ years, PFS, A or better at SSLLabs. 
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices 




signature.asc
Description: Message signed with OpenPGP

Re: SSL and Usability and Safety

[Dirk-Willem van Gulik]

On 3 May 2017, at 10:03, Issac Goldstand  wrote:
> 
> +1 on the idea
> 
> So far I'm -0 about all of the proposed implementations for 2 reasons:
> 
> 1) Mr and Mrs normal (whom are our primary customers in the original
> proposal) usually download Apache from their distro or some other
> binary.  Their Apache sources are usually not up-to-date, and in the
> scenario that a new vulnerability is found it would take ages to
> propagate to them, anyway
> 
> 2) For those users who are comfortable building their own source, they
 ….

So how about ‘us’ taking the lead here. 

We, here, simply define ‘one’ setting as the industry best standard - which 
roughly corresponds to what ssllabs their test would get you an A+ and that 
pretty much meets or exceeds the various NIST et.al. recommendations for key 
lengths for the next 5 years. 

We’d wrap this into a simple policy document. Promise ourselfves that we’d 
check this every release and at least once a year review it. And have a small 
list of the versions currently meeting or exceeding our policy.

And this is the setting you get when you do ‘SSLEngine On’.

Everything else stays as is.

Dw

Re: SHA-256

[Dirk-Willem van Gulik]

On 24 Feb 2017, at 18:52, Jim Jagielski  wrote:
> 
> I think we should start, in addition to "signing" w/ md5 and sha-1,
> using sha-256 as well.
> 
> Sound OK?

That seems to match the advice of NIST, E-CRYPT and the BSI on


https://www.nrc.nl/nieuws/2017/02/24/zelfrijdende-auto-google-uber-stal-onze-robotauto-6964363-a1547533
 


none of which seems that eager to push us to 385 or 512 for the next 4 years. 

Though if we are updating the scripts - perhaps add sha-512 - just to 
‘socialize’ it early.

Dw.

Re: rfc7231 - content-md5

[Dirk-Willem van Gulik]

> On 20 Jan 2017, at 21:13, William A Rowe Jr  wrote:
> 
> On Fri, Jan 20, 2017 at 1:49 PM, William A Rowe Jr  
> wrote:
>> On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik
>>  wrote:
>>> RFC 7231 has retired Content-MD5.
>>> 
>>> Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN 
>>> or INFO and retire it at the next minor release ?
> 
> +1
> 
>> Removing what, precisely? Content-MD5 headers aren't implemented in trunk.
> 
> Sorry, I missed a -i arg to grep :)
> 
Ah ok - thanks - I was wondering I had been in Amsterdam for too long (which I 
had - and it involved shops where they do sell coffee).

> Yes, the default_handler behavior in trunk/server/core.c can simply be 
> removed,
> along with the core.c ContentDigest directive handling. I think it
> should also be
> removed from modules/cache/mod_cache.c as it is not a valid entity header.
> 
> The many unset Content-MD5 actions must remain IMO to guard against our
> sharing this upstream or downstream.
> 
> The http_core.h core flag content_md5 and values AP_CONTENT_MD5_*
> should probably remain until 3.0 to avoid unnecessary API changes. a doxygen
> /** @deprecated Unused flag */ against that struct member will help us mop 
> these
> up during any 3.0 review.

Dw.

Re: rfc7231 - content-md5

[Dirk-Willem van Gulik]

On 20 Jan 2017, at 20:49, William A Rowe Jr  wrote:
> 
> Note that https://www.rfc-editor.org/rfc/rfc7616.txt still provides
> for MD5 hashed
> digest auth keys. So removing this altogether will break mod_auth_digest in a
> manner that breaks existing user auth.
> 

> 
> Note that https://www.rfc-editor.org/rfc/rfc7616.txt still provides
> for MD5 hashed
> digest auth keys. So removing this altogether will break mod_auth_digest in a
> manner that breaks existing user auth.

Right - and these need to stay. These are for interoperability reasons - and 
only affect that.

I think I am getting somewhere - currently going to a handful of packages that 
use ARP
and splitting things into:

apr_digest_64()
apr_digest_128()
apr_digest_256()
apr_digest_512()

for places where the is no cryptographic need and

apr_crypto_digest  ---

with the actual name of a cryptographic algorithm like SHA256, etc. Either 
because
it has a cryptographic need -or- because of interoperability -or- both.

And that seems to yield fairly clean results - which ultimately are conductive 
to
'fips' style flags to 'force' ancient algorithms, like MD5, to be not in 
critical places;
while letting harmless continue.

Dw

Re: rfc7231 - content-md5

[Dirk-Willem van Gulik]

> On 20 Jan 2017, at 20:49, William A Rowe Jr  wrote:
> 
> On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik
>  wrote:
>> RFC 7231 has retired Content-MD5.
>> 
>> Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN 
>> or INFO and retire it at the next minor release ?
> 
> Removing what, precisely? Content-MD5 headers aren't implemented in trunk.

That is odd. I have in 

Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1779019

Quite a few:

> ./modules/cache/mod_cache.c:"Content-MD5",
> ./modules/filters/mod_brotli.c:apr_table_unset(r->headers_out, 
> "Content-MD5");
> ./modules/filters/mod_deflate.c:apr_table_unset(r->headers_out, 
> "Content-MD5");
> ./modules/filters/mod_deflate.c:
> apr_table_unset(r->headers_in, "Content-MD5");
> ./modules/filters/mod_deflate.c:apr_table_unset(r->headers_out, 
> "Content-MD5");
> ./modules/filters/mod_filter.c:
> apr_table_unset(r->headers_out, "Content-MD5");
> ./modules/lua/mod_lua.c:apr_table_unset(r->headers_out, 
> "Content-MD5");
> ./server/core.c:apr_table_setn(r->headers_out, "Content-MD5",
> ./server/protocol.c:apr_table_unset(rnew->headers_in, "Content-MD5");

Did I fuck up my repo in an epic way?

Dw

rfc7231 - content-md5

[Dirk-Willem van Gulik]

RFC 7231 has retired Content-MD5.

Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN or 
INFO and retire it at the next minor release ?

Dw.

Re: mod_lets-encrypt

[Dirk-Willem van Gulik]

> On 14 Jan 2017, at 22:31, William A Rowe Jr  wrote:
> 
> On Sat, Jan 14, 2017 at 12:15 PM, Dirk-Willem van Gulik
>  wrote:
>> 
>> On 14 Jan 2017, at 19:05, William A Rowe Jr  wrote:
>> 
>> Any mod_letsencrypt can provision the certs but needs to do so
>> while still root, before servicing requests (although there could be
>> some bounce-step where the MPM begins satisfying requests,
>> including the verification request necessary for letsencrypt.) We
>> certainly don't want to parse any web response whatsoever while
>> running as root.
>> 
>> Some of this will be needed - we need to be root to bind to port 80 — as the
>> protocol (in my reading) seems to demand it (now would be a good time to
>> petition the draft to change this for a random higher port).
>> 
>> In fact - that may be a nice feature - an, essential, empheral port.
> 
> My thinking was more along the lines that we fork off a process, much like
> mod_cgid or mod_ftp does to handle low numbered ports. What is actually
> handed across the domain socket or equivalent is structured simply enough
> to not be harmed by an errant child process, or if needed by the server
> earlier, then forked with the lesser run-as-httpd user permissions to speak
> some predictable and strictly constructed message back up to the root parent
> process.
> 
> It might be nice to our users if the cert/key isn't in the keystore,
> that the server
> starts anyways with a dummy cert, until it finally resolves to the
> letsencrypt CA
> server and completes that handshake.

Technically there is no need from this from a lets-encrypt perspective. Just 
port 80 for a few seconds.

> The server can respond to that child
> process modifying the keystore and exiting by initiating a graceful restart to
> begin serving traffic with the newly obtained cert/key material.

So the process of registering afresh; sending the tokens and getting the certs 
takes seconds at the very most.

So I’d be quite willing to allow a server to not start up an stay in a very 
simple mode prior to this.

An option may be to suid/chroot and what not down - and just hand the child a 
filedescriptor
to which it has write only for just the key - after which it dies.

But fair to assume we can hold of starting the server; it is pretty common to 
see 2-3 seconds
of cycle time due to DNS and what not already.

And anyone who understands/cares can do a dead normal setup using SSL 
thing-a-me’s.

or am I getting the scope wrong ?

> Somewhere in this equation lies accessor functions to mod_ssl to allow us
> access to keystores. Which would be a very useful facility, well beyond just
> letsencrypt. Whether those cert/key pairs live in ldap or some other place.
> Imagine a small cluster, say 4 instances of httpd, where only one performs
> the letsencrypt dance and the others search a memcache or other remote
> resource for the resulting cert/key materials (locked down well, we would
> hope.)

Agreed - but think that this is an ortogonal isue - and have sofar found that
with things like chipcards and HSM - the openssl engines are doing splendidly.

Dw.

Re: mod_lets-encrypt

[Dirk-Willem van Gulik]

> On 14 Jan 2017, at 20:05, Stefan Sperling  wrote:
> 
> On Sat, Jan 14, 2017 at 07:15:29PM +0100, Dirk-Willem van Gulik wrote:
>> In fact - that may be a nice feature - an, essential, empheral port.
> 
> Would that work for web servers behind firewalls?

No; would not expect so. Am willing to declare such more or less out of scope 
for a simple apache module — i.e. if you are in an environment that is that 
‘pro’ that it can do decent firewalls and what not - then running a script like 
dehydrated on cron every 2 weeks to keep your lets-encrypt certs up to date 
should not exactly be beyond you.

But am willing to be convinced that i got the ‘sweet’ spot for this wrong. I am 
amazed by the level of handholding/details people are willing to 
forego/eskew/need in the world of docker containers.

Dw.

Re: mod_lets-encrypt

[Dirk-Willem van Gulik]

> On 14 Jan 2017, at 19:05, William A Rowe Jr  wrote:
> 
> On Sat, Jan 14, 2017 at 10:22 AM, Eric Covener  wrote:
>> On Sat, Jan 14, 2017 at 11:19 AM, Eric Covener  wrote:
>>> 
>>> I think if a feature/directive will turn on something that will write
>>> to configured keystores, it really shouldn't do or dictate much else.
>> 
>> Poorly phrased, but I think obtaining a cert should be separate from
>> things like further SSL configuration.
> 
> I think Dirk is suggesting that the core mod_ssl continues to exist, with
> sane defaults that require next to no specific directives other than to
> perhaps set the https protocol on port 443, and (I vote optionally) have
> a one line toggle for rewriting all port 80 requests to 443.
> 
> Note that h2 requests will continue to be honored on either port 80
> or 443, so this has to be crafted somewhat carefully.
> 
> I'm 100% in support of ensuring that mod_ssl runs with the most
> sensible choices in the most minimal config.
> 
> Any mod_letsencrypt can provision the certs but needs to do so
> while still root, before servicing requests (although there could be
> some bounce-step where the MPM begins satisfying requests,
> including the verification request necessary for letsencrypt.) We
> certainly don't want to parse any web response whatsoever while
> running as root.

Some of this will be needed - we need to be root to bind to port 80 — as the 
protocol (in my reading) seems to demand it (now would be a good time to 
petition the draft to change this for a random higher port).

In fact - that may be a nice feature - an, essential, empheral port.

And we will need to be able to respond to an HTTP request to a well known URL 
with the public key/token — and post that have some fork/pid be root enough to 
write a few things to safe places.

> I do believe the proposal should require a one line directive to
> enable this, particularly for the compiled-in static many modules
> build of httpd. It's shouldn't be simply a matter of loading some
> mod_letsencrypt without also some 'LetsEncrypt on" directive
> in the ssl vhost config.

The alternative is bundling a small shell script, like  stripped down
‘dehydrate’:

https://github.com/lukas2511/dehydrated/blob/master/dehydrated 


as a tool. And augment it with examples. But then you are back to square one.

Dw.

Re: mod_lets-encrypt

[Dirk-Willem van Gulik]

(reshuffled top post)

On 14 Jan 2017, at 16:07, Rich Bowen  wrote:
> On Jan 10, 2017 12:15 PM, "Jacob Champion"  <mailto:champio...@gmail.com>> wrote:
> On 01/10/2017 08:35 AM, Dirk-Willem van Gulik wrote:
> Before I send someone into the woods - did anyone consider/do a quick
> ‘mod_lets_encrypt’ (with or without a persistent store) — that
> requires virtually no configuration ?
> 
> Considered? Yes. Back in August there was some discussion on this list with 
> Josh Aas. I don't know what the current status is.
..
> https://lists.apache.org/thread.html/ea902ae8e453b3a8d36345318fc74a54880d8bf14fed24e665c4b833@%3Cdev.httpd.apache.org%3E
>  
> <https://lists.apache.org/thread.html/ea902ae8e453b3a8d36345318fc74a54880d8bf14fed24e665c4b833@%3Cdev.httpd.apache.org%3E>
...
> https://lists.apache.org/thread.html/27d1fce7d30d9e31e2472045c260e4f8dcefd300a731ff9e435a5d4a@%3Cdev.httpd.apache.org%3E
>  
> <https://lists.apache.org/thread.html/27d1fce7d30d9e31e2472045c260e4f8dcefd300a731ff9e435a5d4a@%3Cdev.httpd.apache.org%3E>
> I talked with him at linuxcon, but there's been no followup. I for one would 
> love to see this happen.

So it seems we currently pull in enough sundry into mod_ssl to barely need 
something as ‘big’ as:

https://github.com/kristapsdz/acme-client 

if we assume the HTTP method (only) — which makes sense if we assume that this 
module is first and foremost about zero configuration and convenience. 

By extend that also means we ‘trust’ ourselves and the user we start up as 
(prior to any fork, suid or chrooting).

So I think we can narrow this down a lot (I just had to put something like this 
into a simple XMPP system) - as anyone who wants to do something more complex 
can use the many scripts available or use ‘real’ CA request processes.

So we are talking about the configs which are as simple as

# Defaults to /var/httpd/acme-private or something like we do for 
Mutexes.
#
ACMEDir /var/db/httpd/acme-private


ACME automatic
…

Where this implies SSLEnable, a set of sane/best-practice. ‘A+’, set of 
baseline SSL directives w.r.t. OSCP stapling  and so on. And absolutely no 
further SSL statements in your vhost. And it implies that port 80 forwards to 
https. Perhaps disallow any port/listen stuff ?

If you need SSL statements — then you are out of scope ? Is that fair ?

Which reduces the footprint to:

-   fetching the ACME-CA-URLs on first run ever; on install —or— having 
these as part of the distribution.

=> Fair to assume we ship with the ACME CA url ?

-   pin the server.

-   reading -or- generating an RSA key & 0600 storing it in what we 
consider a safe enough place (prior to any chroot)ing. 

=> Fair to assume key rollover is out of scope for this key (we could 
even do this empheral - and regenerate on renewal) ?

=> Fair to assume we just use one for all domains ?

-   Register this on first run. 

=>  Fair to assume things like contact email and EULA ok are out of 
scope ?

-   Build up a cert for each vhost; with all aliases added too as altnames. 

- for each vhost (altname) — get a challenge from the ACME server.

=>  Fair to assume we do not care about account recovery ?

-   bring up that/all vhost on their port 80  (all vhosts that have 
LetsEncrypt set to auto/on).

=> so if I understand the spec right - only port 80

==>  thus fair to assume non-root startup is out of 
scope - as we need to bind to a port < 1024.

So therefore:
=> fair to configure this ‘easier’ — i.e. if you do 
LetsEnrypt on on a domain SSL auto switches on and port 80 becomes an automatic 
redirect to https ?

-   Respond to the well know URI with each of he challenges.

-   Fetch/poll for the cert; save with 0600 and tight UID and be done.

-   Gracefully fail for each domain after N seconds - blocking https and 
with a sorry no ACME on http.

=>  do we need to allow for an ErrorDocument customisation of the 
latter ?

-   Set up a sane virtual SSL set of directives; and then chroot/suid/fork 
and start your normal run.

-   Switch of http or make http a blind to https forwarder.

-   Can we assume that the server has a graceful restart every week ? 

=> And thus declare ACME renewal from within out of scope  ?

Or do we need to auto disable SSL and go to http ?

Does that make sense - or have I oversimplified it and lost the plot ?

Dw

mod_lets-encrypt

[Dirk-Willem van Gulik]

Before I send someone into the woods - did anyone consider/do a quick 
‘mod_lets_encrypt’ (with or without a persistent store) — that requires 
virtually no configuration ?

Or is the web world still thinking unix with clear small concise scripts that 
do one thing well ?

Dw

Re: EC to audit Apache HTTP Server

[Dirk-Willem van Gulik]

On 22 Jul 2016, at 18:59, Steffen  wrote:
> 
> See https://joinup.ec.europa.eu/node/153614

I think I’ve gotten the right people at the EC to know that d Eric Covener 
(cove...@apache.org) as the Chair of HTTPD is the right starting place should 
they want a proper conversation.

Dw (who once upon a time worked at that EC department).

Re: svn commit: r1750779 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_kernel.c

[Dirk-Willem van Gulik]

That is my reading as well - +1.

> On 30 Jun 2016, at 18:38, Jim Jagielski  wrote:
> 
> +1
> 
>> On Jun 30, 2016, at 11:38 AM, Stefan Eissing  
>> wrote:
>> 
>> We now set exactly the same callback right before in line 709. If we had 
>> more than one callback, we would not have to specify NULL, but restore any 
>> previous callback there was, right?
>> 
>> But that is all just theoretical, as You and Yann already stated.
>> 
>>> Am 30.06.2016 um 17:26 schrieb Yann Ylavic :
>>> 
>>> On Thu, Jun 30, 2016 at 5:05 PM, Ruediger Pluem  wrote:
 
 Is there a reson why we use ssl_callback_SSLVerify instead of NULL like we 
 do in asimilar situation below?
 IMHO we do not want to change the callback here to whatever it may set.
 I agree that in practice there won't be any difference right now, since we 
 only have one callback.
>>> 
>>> I agree that if/when we have multiple callback possibilities, we
>>> should set NULL here, but also above where we force the new mode.
>>> 
>>> Nothing to worry about for now, though.
>>> 
>>> Regards,
>>> Yann.
>> 
> 
> 

Odd SSLProxyCheckPeerCN behaviour

[Dirk-Willem van Gulik]

Was looking into a report that something could get a lift on websocket with a 
specific AltSubject trickery; but got into jak shaving - where I cannot work 
out why SSLProxyCheckPeerCN et.al. get ignored. The most trivial config I could 
find to reproduce is:

Listen  123.123.123.123:4321


ServerName test-websock-bypass.webweaving.org   
LogLevel Debug

SSLProxyEngine On

SSLProxyCheckPeerCN off # Not using SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
SSLProxyVerify off


SSLProxyCACertificateFile …./proxy.pem

ProxyPass / https://127.0.0.1:1234/
ProxyPassReverse / https://127.0.0.1:1234/


This getting tested with

beeb:~ dirkx$ curl - https://123.123.123.123:4321/

giving us a 

500 Proxy Error

The proxy server could not handle the request GET /.
Reason: Error during SSL Handshake with remote 
server 

However the log gives me:

[Wed Feb 17 12:18:53.167903 2016] [ssl:debug] [pid 48233] 
ssl_engine_kernel.c(1560): [remote 192.168.0.5:6045] AH02275: Certificate 
Verification, depth 0, CRL checking mode: none [subject: 
emailAddress=root@host.unknown,CN=host.unknown,OU=root / issuer: 
emailAddress=root@host.unknown,CN=host.unknown,OU=root / serial: 2481 / 
notbefore: Feb 10 10:51:12 2016 GMT / notafter: Feb  7 10:51:12 2026 GMT]
[Wed Feb 17 12:18:53.169458 2016] [ssl:debug] [pid 48233] 
ssl_engine_kernel.c(2018): [remote 192.168.0.5:6045] AH02041: Protocol: 
TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
[Wed Feb 17 12:18:53.169508 2016] [ssl:debug] [pid 48233] ssl_util_ssl.c(443): 
AH02412: [weser.webweaving.org:443] Cert does not match for name '192.168.0.5' 
[subject: emailAddress=root@host.unknown,CN=host.unknown,OU=root / issuer: 
emailAddress=root@host.unknown,CN=host.unknown,OU=root / serial: 2481 / 
notbefore: Feb 10 10:51:12 2016 GMT / notafter: Feb  7 10:51:12 2026 GMT]
[Wed Feb 17 12:18:53.169524 2016] [ssl:info] [pid 48233] [remote 
192.168.0.5:6045] AH02411: SSL Proxy: Peer certificate does not match for 
hostname 192.168.0.5
[Wed Feb 17 12:18:53.169541 2016] [ssl:info] [pid 48233] [remote 
192.168.0.5:6045] AH01998: Connection closed to child 0 with abortive shutdown 
(server weser.webweavin

Now AFAIKS - AH02412 is fair game - that is in modssl_X509_match_name() and the 
name does indeed not match.

But I fail to understand the error on AH02411 — it is in ssl_engine_io.c

  if ((sc->proxy_ssl_check_peer_name != SSL_ENABLED_FALSE) &&
hostname_note) {
apr_table_unset(c->notes, "proxy-request-hostname");
if (!cert
|| modssl_X509_match_name(c->pool, cert, hostname_note,
  TRUE, server) == FALSE) {
proxy_ssl_check_peer_ok = FALSE;
ap_log_cerror(APLOG_MARK, APLOG_INFO, 0, c, APLOGNO(02411)
  "SSL Proxy: Peer certificate does not match "
  "for hostname %s", hostname_note);
}
}
else if ((sc->proxy_ssl_check_peer_cn != SSL_ENABLED_FALSE) &&
hostname_note) {
const char *hostname;
int match = 0;

So I am now wondering about this logic in case of no alternative subject. And 
if superseding it was good enough - or if it should be totally removed. OR if 
this check needs to become an either/or check if there is no subject 
alternative).

Dw

Re: Buffer size in mod_session_crypto.c, decrypt_string()

[Dirk-Willem van Gulik]

> On 19 Nov 2015, at 10:07, Ewald Dieterich  wrote:
> 
> This is from mod_session_crypto.c, decrypt_string():
> 
>/* strip base64 from the string */
>decoded = apr_palloc(r->pool, apr_base64_decode_len(in));
>decodedlen = apr_base64_decode(decoded, in);
>decoded[decodedlen] = '\0';
> 
> Shouldn't that be ("+ 1" for the added '\0'):
> 
>   decoded = apr_palloc(r->pool, apr_base64_decode_len(in) + 1);
> 
> At least that's how it's done in eg. mod_auth_basic.c. Or can we make any 
> assumptions about the number of characters that apr_base64_decode_len() 
> returns?
> 

Hmm - very strong feeling of a deja vu:  
https://bz.apache.org/bugzilla/show_bug.cgi?id=43448 
  from some 10 years ago 
(it blew something out of the water back then).

And pretty sure we fixed the documentation. _len() returns the max size of the 
buffer (i.e. + 1). 

And _decode the exact length of the string without the trailing \0 which it 
silently does add. And which may be shorter than _len.

So above should be fine — but the 

>decoded[decodedlen] = '\0’;

seems both confusing and superfluous. Alternatively one could use 
_decode_binary()  in which case above terminator is absolutely needed. There is 
no _binary_len().

Dw

Good at assembler ? (Was:httpd - side channel attack - timing of digest comparisons)

[Dirk-Willem van Gulik]

>>> On 28 May 2015, at 17:03, William A Rowe Jr >> <mailto:wr...@rowe-clan.net>> wrote:
….
>>> > > On 26 May 2015, at 17:22, Dirk-Willem van Gulik >> > > <mailto:di...@webweaving.org>> wrote:
>>> > ..
>>> > > So I think that what is needed are two (or three) functions
>>> > ...
>>> > > - A string comparison function; where at least one string is is 
>>> > > under control of the attacker.
>>> 
Thanks for all the feedback. With a bit of help from Martijn Boekhorst and Andy 
Armstrong I got as far as:

https://gist.github.com/dirkx/37c29dc5a82b6deb0bf0 
<https://gist.github.com/dirkx/37c29dc5a82b6deb0bf0>

which I am now testing against a wide range of settings & compilers (in essence 
running a side channel attack on it and see how far I get with the various 
variations).

However I could use some help & manual inspection ?

So if you have the time & can read assembler well - can you compile this at a 
reasonable optimizer setting and look at the assembler to confirm that key 
elements are not somehow optimized away; i.e. the innner loop is running in 
constant time. I am fairly sure about what happens on ARM and x386 — but modern 
x86 is largely voodoo to me.

Secondly - when we get to the end of the shorter string; we can either keep 
comparing to the last char or \0; or we go ‘modulo’ to the start of the string. 
Now modulo is perhaps not ideal; and seems to affect the pipeline on the XEON 
cpu (something I confess not to quite understand; and I cannot see/replicate on 
ARM).

So I would also love to have feedback on the two strategies in the code w.r.t. 
to that - and not getting hit by pipeline length; L3 caches or odd things like 
page boundaries.

Above GIST has the full code - the simpliefied version below (which does not 
have the 1024 min length).

Dw.



// MODULO version

AP_DECLARE(int) ap_timingsafe_strcmp(const char * hostile, const char * 
toProtect) {
const unsigned char *p1 = (const unsigned char *)hostile;
const unsigned char *p2 = (const unsigned char *) toProtect;

size_t i1 = 1 ,i2 = 1;
unsigned int d1 = 1, d2 = 1, res = 0;
do {
res |= (p1[i % i1] - p2[i % i2]);
 
d1 &= !!p1[i % i1];
d2 &= !!p2[i % i2];

i1 += d1;
i2 += d2;
i++; 
} while (d1); // we reveal the length of the hostile string.

res |= (i1 - i2);
 
return (int) res;
}
 

// Cycle at last char version

AP_DECLARE(int) ap_timingsafe_strcmp(const char * hostile, const char * 
toProtect) {
const unsigned char *p1 = (const unsigned char *)hostile;
const unsigned char *p2 = (const unsigned char *)toProtect;

size_t i1 = 0 ,i2 = 0;
unsigned int d1 = 1, d2 = 1, res = 0;
 
do {
res |= (p1[i1] - p2[i2]);

d1 &= !!p1[i1];
d2 &= !!p2[i2];

i1 += d1;
i2 += d2;
i++;
} while (d1); // we reveal the length of the hostile string. Use 
(d1|d2) and a min run-length to hide both.

res |= (i1 - i2);
 
return (int) res;
}

Re: httpd - side channel attack - timing of digest comparisons

[Dirk-Willem van Gulik]

> On 28 May 2015, at 17:24, Dirk-Willem van Gulik  wrote:
> 
> 
>> On 28 May 2015, at 17:03, William A Rowe Jr > <mailto:wr...@rowe-clan.net>> wrote:
>> 
>> 
>> On May 26, 2015 10:31 AM, "Dirk-Willem van Gulik" > <mailto:di...@webweaving.org>> wrote:
>> >
>> >
>> > > On 26 May 2015, at 17:22, Dirk-Willem van Gulik > > > <mailto:di...@webweaving.org>> wrote:
>> > ..
>> > > So I think that what is needed are two (or three) functions
>> > ...
>> > > - A string comparison function; where at least one string is is 
>> > > under control of the attacker.
>> >
>> > Now the issue here is that length is every easily revealed. So I can think 
>> > of 2 strategies;
>> >
>> > -   firmly declare (in the signature of the compare function) one 
>> > argument as potentially hostile.
>> >
>> > And do the comparison largely based on that; which means we only 
>> > marginally reveal the
>> > actual length of the string compared to. Below is an example; but 
>> > my gut feel it is not
>> > nearly good enough when you can apply a large chunk of statistics 
>> > against it.
>> >
>> > -   treat them both as hostile; and scan for either the shortest or 
>> > longest one and accept
>> > that you leak something about length.
>> >
>> > Or - if needed - pad this out for strings <1024 (or similar) chars 
>> > in length by doing always
>> > that many (which will leak less).
>> >
>> > Examples are below. Suggestions appreciated.
>> >
>> > Dw.
>> >
>> > static int or_bits(int  x) {
>> >   x |= (x >> 4);
>> >   x |= (x >> 2);
>> >   x |= (x >> 1);
>> >   return -(x & 1);
>> > }
>> >
>> > /* Quick mickey mouse version to compare the strings. XXX fixme.
>> >  */
>> > AP_DECLARE(int) ap_timingsafe_strcmp(const char * hostile_string, const 
>> > char * to_protect__string) {
>> > const unsigned char *p1 = (const unsigned char *)hostile_string;
>> > const unsigned char *p2 = (const unsigned char 
>> > *)to_protect__string;
>> > size_t i = 0, i1 = 0 ,i2 = 0;
>> > unsigned int res = 0;
>> > unsigned int d1, d2;
>> >
>> > do {
>> > res |= or_bits(p1[i1] - p2[i2]);
>> >
>> > d1 = -or_bits(p1[i1]);
>> > d2 = -or_bits(p2[i2]);
>> >
>> > i1 += d1;
>> > i2 += d2;
>> > i += (d1 | d2);
>> >
>> > #icase A
>> > } while (d1 | d2); // longest one will abort
>> > #case B
>> > } while (d1 & d2); // shortest one will abort
>> > #case C
>> > } while (i < 1024) } while (d1 | d2); // at least 1024 or longest 
>> > one/shortest one
>> >
>> > // include the length in the coparision; as to avoid foo v.s. 
>> > foofoofoo to match.
>> > //
>> > return (int) (res | ( i1 - i2));
>> > }
>> 
>> Giving this some thought for the string version, does it make sense to loop 
>> the underflow string back to offset zero on EOS?  There is a certain amount 
>> of cache avoidance that could cause, but it would dodge the optimization of 
>> that phase and ensure the longest-match comparisons are performed (measured 
>> by the untrusted input, presumably).
>> 
> So I am currently experimenting with 
> 
>   https://gist.github.com/dirkx/37c29dc5a82b6deb0bf0 
> <https://gist.github.com/dirkx/37c29dc5a82b6deb0bf0>
> 
> which seems to behave reasonably and does not get optimized out too far.  We 
> could perhaps do something where we change the i1/i2 loop indexes
> by str[i % i1] instead of i1/i2 that ‘stop’; and keep i1 one higher than i 
> until we hit the \0.

Updated the above gist with your idea (also shown below).

Dw.

/* Quick mickey mouse version to compare the strings. XXX fixme. 
 */
typedef enum ap_compareflag_t {
AP_HOSTILE_STR1 = 1,  // if a string is ‘hostile’ - we’re fine to abort 
on it early.
AP_HOSTILE_STR2 = 2, // otherwise we hide its length by checking it for 
the length of the other (or both).
AP_MIN1024 = 4   // pretend that they are at least 1024 chars in 
size.
} ap_compareflag_t;
 
AP_DECLARE(int) ap_timingsafe_strcm

Re: httpd - side channel attack - timing of digest comparisons

[Dirk-Willem van Gulik]

> On 28 May 2015, at 17:03, William A Rowe Jr  wrote:
> 
> 
> On May 26, 2015 10:31 AM, "Dirk-Willem van Gulik"  <mailto:di...@webweaving.org>> wrote:
> >
> >
> > > On 26 May 2015, at 17:22, Dirk-Willem van Gulik  > > <mailto:di...@webweaving.org>> wrote:
> > ..
> > > So I think that what is needed are two (or three) functions
> > ...
> > > - A string comparison function; where at least one string is is under 
> > > control of the attacker.
> >
> > Now the issue here is that length is every easily revealed. So I can think 
> > of 2 strategies;
> >
> > -   firmly declare (in the signature of the compare function) one 
> > argument as potentially hostile.
> >
> > And do the comparison largely based on that; which means we only 
> > marginally reveal the
> > actual length of the string compared to. Below is an example; but 
> > my gut feel it is not
> > nearly good enough when you can apply a large chunk of statistics 
> > against it.
> >
> > -   treat them both as hostile; and scan for either the shortest or 
> > longest one and accept
> > that you leak something about length.
> >
> > Or - if needed - pad this out for strings <1024 (or similar) chars 
> > in length by doing always
> > that many (which will leak less).
> >
> > Examples are below. Suggestions appreciated.
> >
> > Dw.
> >
> > static int or_bits(int  x) {
> >   x |= (x >> 4);
> >   x |= (x >> 2);
> >   x |= (x >> 1);
> >   return -(x & 1);
> > }
> >
> > /* Quick mickey mouse version to compare the strings. XXX fixme.
> >  */
> > AP_DECLARE(int) ap_timingsafe_strcmp(const char * hostile_string, const 
> > char * to_protect__string) {
> > const unsigned char *p1 = (const unsigned char *)hostile_string;
> > const unsigned char *p2 = (const unsigned char *)to_protect__string;
> > size_t i = 0, i1 = 0 ,i2 = 0;
> > unsigned int res = 0;
> > unsigned int d1, d2;
> >
> > do {
> > res |= or_bits(p1[i1] - p2[i2]);
> >
> > d1 = -or_bits(p1[i1]);
> > d2 = -or_bits(p2[i2]);
> >
> > i1 += d1;
> > i2 += d2;
> > i += (d1 | d2);
> >
> > #icase A
> > } while (d1 | d2); // longest one will abort
> > #case B
> > } while (d1 & d2); // shortest one will abort
> > #case C
> > } while (i < 1024) } while (d1 | d2); // at least 1024 or longest 
> > one/shortest one
> >
> > // include the length in the coparision; as to avoid foo v.s. 
> > foofoofoo to match.
> > //
> > return (int) (res | ( i1 - i2));
> > }
> 
> Giving this some thought for the string version, does it make sense to loop 
> the underflow string back to offset zero on EOS?  There is a certain amount 
> of cache avoidance that could cause, but it would dodge the optimization of 
> that phase and ensure the longest-match comparisons are performed (measured 
> by the untrusted input, presumably).
> 
So I am currently experimenting with 

https://gist.github.com/dirkx/37c29dc5a82b6deb0bf0 
<https://gist.github.com/dirkx/37c29dc5a82b6deb0bf0>

which seems to behave reasonably and does not get optimized out too far.  We 
could perhaps do something where we change the i1/i2 loop indexes
by str[i % i1] instead of i1/i2 that ‘stop’; and keep i1 one higher than i 
until we hit the \0.

Dw

Re: mod_h2 internals

[Dirk-Willem van Gulik]

> On 28 May 2015, at 16:25, Jim Jagielski  wrote:
> 
> One thing I've been thinking about, and there might even be some hooks
> in trunk for it, is the idea of slave connections (or sub-connections)
> which kind of *is* a pseudo connection. So one could create a connection
> and then a sub/slave connection from that, and then use *that* for
> requests. This maintains the connection->request idea, but allows for
> multiple connections and requests per a single "real" connection.

That would be useful - and perhaps fold/kill some of the internal redirect 
stuff in as well.

Dw.

Re: httpd - side channel attack - timing of digest comparisons

[Dirk-Willem van Gulik]

> On 26 May 2015, at 17:22, Dirk-Willem van Gulik  wrote:
..
> So I think that what is needed are two (or three) functions
...
> - A string comparison function; where at least one string is is under 
> control of the attacker.

Now the issue here is that length is every easily revealed. So I can think of 2 
strategies;

-   firmly declare (in the signature of the compare function) one argument 
as potentially hostile.

And do the comparison largely based on that; which means we only 
marginally reveal the
actual length of the string compared to. Below is an example; but my 
gut feel it is not
nearly good enough when you can apply a large chunk of statistics 
against it.

-   treat them both as hostile; and scan for either the shortest or longest 
one and accept
that you leak something about length.

Or - if needed - pad this out for strings <1024 (or similar) chars in 
length by doing always
that many (which will leak less).

Examples are below. Suggestions appreciated. 

Dw.

static int or_bits(int  x) {
  x |= (x >> 4);
  x |= (x >> 2);
  x |= (x >> 1);
  return -(x & 1);
}

/* Quick mickey mouse version to compare the strings. XXX fixme. 
 */
AP_DECLARE(int) ap_timingsafe_strcmp(const char * hostile_string, const char * 
to_protect__string) {
const unsigned char *p1 = (const unsigned char *)hostile_string;
const unsigned char *p2 = (const unsigned char *)to_protect__string;
size_t i = 0, i1 = 0 ,i2 = 0;
unsigned int res = 0;
unsigned int d1, d2;

do {
res |= or_bits(p1[i1] - p2[i2]);

d1 = -or_bits(p1[i1]);
d2 = -or_bits(p2[i2]);

i1 += d1;
i2 += d2;
i += (d1 | d2);

#icase A
} while (d1 | d2); // longest one will abort
#case B
} while (d1 & d2); // shortest one will abort
#case C
} while (i < 1024) } while (d1 | d2); // at least 1024 or longest 
one/shortest one

// include the length in the coparision; as to avoid foo v.s. foofoofoo 
to match.
//
return (int) (res | ( i1 - i2));
}

Re: httpd - side channel attack - timing of digest comparisons

[Dirk-Willem van Gulik]

Folks,

Did a scan through a fair bit of our code. mod_digest is not the only place; 
e.g. in basic auth; we are also
not as careful in all cases as we could be. 

So I think that what is needed are two (or three) functions

-   A fairly mundane (binary) timing safe compare that compares two fixed 
lengths (e.g. SHA or MD5) 
strings or binary buffers.

-   A string comparison function; where at least one string is is under 
control of the attacker.

As to the first - I think it can be as simple as below - as to the latter - see 
next email. As with that one I am struggling.

Dw

/* Oroginal code for ap_timingsafe_memcmp: libressl-portable under below 
license. 
 *
 * Copyright (c) 2014 Google Inc.
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all cop1es.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

/**
 * Compare two binary buffers (of identical length) in a timing safe
 * manner. As to avoid leaking information about that what is compared
 * and thus preventing side channel leaks when for example comparing
 * a checksum or a password.
 *.
 * Both buffers are assumed to have idenitcal length.
 *
 * @param   buf1Buffer 1 to compare buffer 2 to.
 * @param   buf2Buffer 2 
 * @param   len The length of the two buffers.
 * @return  0 when identical, non zero when different.
 */
AP_DECLARE(int) ap_timingsafe_memcmp(const void *b1, const void *b2, size_t len)
{
const unsigned char *p1 = b1, *p2 = b2;
size_t i;
int res = 0, done = 0;

for (i = 0; i < len; i++) {
/* lt is -1 if p1[i] < p2[i]; else 0. */
int lt = (p1[i] - p2[i]) >> CHAR_BIT;

/* gt is -1 if p1[i] > p2[i]; else 0. */
int gt = (p2[i] - p1[i]) >> CHAR_BIT;

/* cmp is 1 if p1[i] > p2[i]; -1 if p1[i] < p2[i]; else 0. */
int cmp = lt - gt;

/* set res = cmp if !done. */
res |= cmp & ~done;

/* set done if p1[i] != p2[i]. */
done |= lt | gt;
}

return (res);
}

Re: httpd - side channel attack - timing of digest comparisons

[Dirk-Willem van Gulik]

Very quick and dirty list of the most obvious places where we compare stuff. 
Currently trying to find some time to figure out if these are all vulnerable; 
or if it is just the two outer ones.

Dw.

Index: modules/aaa/mod_auth_digest.c
===
--- modules/aaa/mod_auth_digest.c   (revision 1680471)
+++ modules/aaa/mod_auth_digest.c   (working copy)
@@ -1394,7 +1394,7 @@
 resp->nonce[NONCE_TIME_LEN] = tmp;
 resp->nonce_time = nonce_time.time;
 
-if (strcmp(hash, resp->nonce+NONCE_TIME_LEN)) {
+if (ap_timingsafe_strcmp(hash, resp->nonce+NONCE_TIME_LEN)) {
 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01776)
   "invalid nonce %s received - hash is not %s",
   resp->nonce, hash);
@@ -1423,7 +1423,7 @@
 }
 }
 else if (conf->nonce_lifetime == 0 && resp->client) {
-if (memcmp(resp->client->last_nonce, resp->nonce, NONCE_LEN)) {
+if (ap_timingsafe_memcmp(resp->client->last_nonce, resp->nonce, 
NONCE_LEN)) {
 ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, APLOGNO(01779)
   "user %s: one-time-nonce mismatch - sending "
   "new nonce", r->user);
@@ -1749,7 +1749,7 @@
 
 if (resp->message_qop == NULL) {
 /* old (rfc-2069) style digest */
-if (strcmp(resp->digest, old_digest(r, resp, conf->ha1))) {
+if (ap_timingsafe_strcmp(resp->digest, old_digest(r, resp, 
conf->ha1))) {
 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01792)
   "user %s: password mismatch: %s", r->user,
   r->uri);
@@ -1784,7 +1784,7 @@
 /* we failed to allocate a client struct */
 return HTTP_INTERNAL_SERVER_ERROR;
 }
-if (strcmp(resp->digest, exp_digest)) {
+if (ap_timingsafe_strcmp(resp->digest, exp_digest)) {
 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01794)
   "user %s: password mismatch: %s", r->user,
   r->uri);

Index: include/util_md5.h
===
--- include/util_md5.h  (revision 1680471)
+++ include/util_md5.h  (working copy)
@@ -64,6 +64,35 @@
  */
 AP_DECLARE(char *) ap_md5digest(apr_pool_t *p, apr_file_t *infile);
 
+/**
+ * Compare two binary buffers (of identical length) in a timing safe
+ * manner. As to avoid leaking information about that what is compared
+ * and thus preventing side channel leaks when for example comparing
+ * a checksum or a password.
+ *.
+ * Both buffers are assumed to have idenitcal length.
+ *
+ * @param   buf1Buffer 1 to compare buffer 2 to.
+ * @param   buf2Buffer 2 
+ * @param   len The length of the two buffers.
+ * @return  0 when identical, non zero when different.
+ */
+AP_DECLARE(int) ap_timingsafe_memcmp(const void *b1, const void *b2, size_t 
len)
+
+/**
+ * Compare \0 terminated strings in a time safe manner.
+ * As to avoid leaking information about that what is compared
+ * and thus preventing side channel leaks when for example comparing
+ * a checksum or a password.
+ *.
+ * Both buffers are assumed to have idenitcal length.
+ *
+ * @param   str1   pointer to a \0 terminated string,
+ * @param   str2   pointer to a \0 terminated string.
+ * @return  0 when identical or both NULL, non zero when different or one of 
the string pointers is NULL.
+ */
+AP_DECLARE(int) ap_timingsafe_strcmp(const char * str1, const char * str2);
+
 #ifdef __cplusplus
 }
 #endif

Index: server/util_md5.c
===
--- server/util_md5.c   (revision 1680471)
+++ server/util_md5.c   (working copy)
@@ -164,3 +164,137 @@
 return ap_md5contextTo64(p, &context);
 }
 
+/* Oroginal code for ap_timingsafe_memcmp: libressl-portable under below 
license. 
+ *
+ * Copyright (c) 2014 Google Inc.
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/**
+ * Compare two binary buffers (of identical length) in a timing safe
+ * manner. As to avoid leaking information about that what is compared
+ * and thus preventing side channel leaks when for example comparing
+ * a checksum or a password.
+ *.

httpd - side channel attack - timing of digest comparisons

[Dirk-Willem van Gulik]

Folks,

security@ got a notification of a potential side channel attack. The original 
message is below (sans details on the poster who wants to remain private).

In short - we’re comparing the digest in mod-auth-digest in a manner that may 
reveal how much is actually correct; leading potentially to a timing attack.

After discussing this on security@ we surmised that the risks are not overly 
high; and that fixing this may warrant some wider discussion/more eyeballs 
across the code base for similar things.

Options discussed sofar on security@ and general thoughts are:

1)  adding a timing safe compare to util_md5.c (for now) with 
an idea to move this to APR longer term.

Besides the link below - 
https://github.com/jedisct1/libsodium/blob/master/src/libsodium/sodium/utils.c#L82
 

 
and the openbsd one was mentioned.

2)  The mail below just comparison; there is an earlier strcmp
comparision there as well.

3)  In general - string comparisons are more messy; as there is the length 
(difference)
issue that is harder to hide. And moving the comparision into sha/md5 
space is
not trivial without a length related side channel on the checksum.

4)  Is this also a moment to reconsider the use of md5; and go to a decent 
SHA ?

5)  We have lots of other places which may need a bit of thought; Yann 
mentioned places
like: Eg. strncmp(), strlen(), str[n]cat(), memcpy() and memcmp() are 
used
by apr_md5_encode(), apr_password_validate(), apr_sha1_update(), …

Avoiding timing attacks requires at least to not use these functions
in APR crypto, and have their equivalent there, and then use them
where appropriate in httpd.

Thanks,

Dw.

>>  Forwarded Message 
>> Subject: httpd: Side Channel Attack
>> Date: Tue, 19 May 2015 18:15:57 +0700
>> 
>> Hi There,
>> 
>> Since memcmp() performs a "byte-by-byte" comparison and do not execute
>> in constant-time, you need to use a better function.
>> 
>> Vuln code which is vulnerable to timing attacks:
>> 
>> -
>> ./modules/slotmem/mod_slotmem_shm.c:215: if (memcmp(digest, digest2,
>> APR_MD5_DIGESTSIZE)) {
>> 
>> ./modules/aaa/mod_auth_digest.c:1426: if
>> (memcmp(resp->client->last_nonce, resp->nonce, NONCE_LEN)) {
>> 
>> ./modules/ssl/ssl_ct_log_config.c:282: if (memcmp(computed_log_id,
>> log_id_bin, LOG_ID_SIZE)) {
>> -
>> 
>> Please take a look memcmp_nta() http://lkml.org/lkml/2013/2/10/13 
>> 

Re: Style checker?

[Dirk-Willem van Gulik]

> I still develop in what a lot of folks would consider a fairly "primitive" 
> environment (vi) that doesn't do anything for style checking things like line 
> width/spacing before and after control statements/indentation/variable 
> declaration/etc. I know of the indent tool available on most unix-like 
> systems, but was wondering if you folks use any other tools to help along 
> that path?

Once upon a time 
https://svn.apache.org/repos/asf/httpd/httpd/tags/1.3/APACHE_1_3a1/src/.indent.pro
 

 was used which grew to about 
http://code.openhub.net/file?fid=q84uxUJ8kEH2vVim-QkGoSiCzoc&cid=h1J7pf7LYjw&s=&fp=305270&mp&projSelected=true#L0
 

 — but I suspect that it is way out of date.

Dw.

Re: Version check idea

[Dirk-Willem van Gulik]

On 21 Apr 2015, at 15:55, Jim Jagielski  wrote:

> For comment: What do people think about adding the capability that
> when httpd is started, it tries to access http://httpd.apache.org/doap.rdf
> to check its version number with the latest one referred to in that
> file and, if a newer one exists, it prints out a little message
> in the error.log (or stderr)…

First reaction - Eek && Evil ! Breaks about every assumption I have about well 
defined unix programmes.

However if it where something like ‘httpd C / --configcheck’ or similarily for 
apachectl then I could easily image that to be rather useful.

Dw.

Re: [Patch] mod_ssl SSL_CLIENT_CERT_SUBJECTS - access to full client certificate chain

[Dirk-Willem van Gulik]

> On 06 Nov 2014, at 14:14, Andreas B.  wrote:
> 
> Am 06.11.2014 um 08:34 schrieb Dirk-Willem van Gulik:
>>> On 06 Nov 2014, at 07:05, Kaspar Brand  
>>> <mailto:httpd-dev.2...@velox.ch> wrote:
>>> 
>>>> 11.3.1 Certificate exact match
>>>> …
>>>>  CertificateExactAssertion ::= SEQUENCE {
>>>>  serialNumber  CertificateSerialNumber,
>>>>  issuerName }
>> ...
>>> (i.e., we are again back at the point that uniqueness of an X.509
>>> certificate is achieved by its issuer DN plus serial number)
>> And even that is LDAPs take on it - in a lot of practical cases it gets more 
>> complex; especially if the leave of the  one but last intermediate is cross 
>> signed.
>> 
>> Making above more of an LDAP thing than a ‘protocol’ thing.
>> 
>> So therefore:
>> 
>>>> Is there another way to do this?
>>> "Manually" performing what certificateExactMatch is specifying, I would
>>> say - i.e., use the (SSL_CLIENT_M_SERIAL,SSL_CLIENT_I_DN) tuple as a
>>> unique identifier for a specific client certificate.
>> I would argue that the ‘best’ thing we can do is first on the SSL 
>> termination side — follow the chain; and if there we *conclude* that all is 
>> well - and we present the evidence of that conclusion ’to what is behind’.
>> 
>> And ideally make that as hard to mis-interpret. So Graham his idea of 
>> providing a single ‘unique' string which gives the DN’s in order (along with 
>> the usual SSL_CLIENT.. env vars; including the full ANS.1 if you are so 
>> inclined) is quite pragmatic. As that string is ‘unique’ within the promise 
>> the web frontend with its current settings is making.
>> 
>> And it cuts out a lot of easy to make errors. And those who want to do 
>> better can simply use SSL_CLIENT_CERT and SSL_CLIENT_CERT_0…N — with 
>> sufficient code to understand things like cross signing and funny order 
>> issues. As parsing that is not trivial when there are multiple 
>> selfsigned/roots in a chain ‘up’.
>> 
>> Dw.
> If you want to identify a specific certificate, wouldn't it be possible to 
> use sha1/256 fingerprints created with X509_digest? Or is that something LDAP 
> doesn't support? That could be exported with SSL_CLIENT_CERT_THUMB and 
> SSL_CLIENT_CERT_THUMB_ALG for the algorithm used.

One could. The issue is that in some systems (e.g. a medical one I am currently 
trying to come to terms with) the certs ar renewed very often; and the 
fingerprint does not stay stable. This is also an issue with using the serial 
and the issuer DN.

Dw.

Re: [Patch] mod_ssl SSL_CLIENT_CERT_SUBJECTS - access to full client certificate chain

[Dirk-Willem van Gulik]

> On 06 Nov 2014, at 07:05, Kaspar Brand  wrote:
> 
>> 11.3.1 Certificate exact match
>> …
>>  CertificateExactAssertion ::= SEQUENCE {
>>  serialNumber  CertificateSerialNumber,
>>  issuerName }
...
> (i.e., we are again back at the point that uniqueness of an X.509
> certificate is achieved by its issuer DN plus serial number)

And even that is LDAPs take on it - in a lot of practical cases it gets more 
complex; especially if the leave of the  one but last intermediate is cross 
signed.

Making above more of an LDAP thing than a ‘protocol’ thing.

So therefore:

>> Is there another way to do this?
> 
> "Manually" performing what certificateExactMatch is specifying, I would
> say - i.e., use the (SSL_CLIENT_M_SERIAL,SSL_CLIENT_I_DN) tuple as a
> unique identifier for a specific client certificate.

I would argue that the ‘best’ thing we can do is first on the SSL termination 
side — follow the chain; and if there we *conclude* that all is well - and we 
present the evidence of that conclusion ’to what is behind’.

And ideally make that as hard to mis-interpret. So Graham his idea of providing 
a single ‘unique' string which gives the DN’s in order (along with the usual 
SSL_CLIENT.. env vars; including the full ANS.1 if you are so inclined) is 
quite pragmatic. As that string is ‘unique’ within the promise the web frontend 
with its current settings is making.

And it cuts out a lot of easy to make errors. And those who want to do better 
can simply use SSL_CLIENT_CERT and SSL_CLIENT_CERT_0…N — with sufficient code 
to understand things like cross signing and funny order issues. As parsing that 
is not trivial when there are multiple selfsigned/roots in a chain ‘up’.

Dw.

Fwd: CVE-2014-3671: DNS Reverse Lookup as a vector for the Bash vulnerability (CVE-2014-6271 et.al.)

[Dirk-Willem van Gulik]

Folks,

You may have spotted below going out.

Hits us tangentially as ap_get_remote_host() gets thus populated; and it can 
then potentially hit a bash shell through variables set in places like ssl, 
setenvif, rewrote, the logger and ajp.

Though by then it is more about input sanitising. I guess one could make a case 
for APR to be a bit more careful with ‘wild’ reverse lookup returns. 

But then again - one should long term gravitate towards UTF8 safeness; so that 
would suggest that dealing with it later in the chain is better.

Dw.


find_allowdeny

> Begin forwarded message:
> 
> Date: 13 Oct 2014 12:03:26 CEST
> From: Dirk-Willem van Gulik 
> To: di...@webweaving.org
> Subject: CVE-2014-3671: DNS Reverse Lookup as a vector for the Bash 
> vulnerability (CVE-2014-6271 et.al.)
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Security Advisory 
> 
>   DNS Reverse Lookup as a vector for the Bash vulnerability (CVE-2014-6271 
> et.al.)
> 
>   CVE-2014-3671
> 
> references:
> CVE-2014-6271, CVE-2014-7169, CVE-2014-6277, CVE-2014-6278 
> CVE-2014-7186 and, CVE-2014-7187
> 
> * Summary:
> 
> Above CVEs detail a number of flaws in bash prior related to the parsing 
> of environment variables  (aka BashBug, Shellshock). Several networked
> vectors for triggering this bug have been discovered; such as through
> dhcp options and CGI environment variables in webservers [1].
> 
> This document is to advise you of an additional vector; through a 
> reverse lookup in DNS; and where the results of this lookup are
> passed, unsanitized, to an environment variable (e.g. as part of
> a batch process). 
> 
> This vector is subtly different from a normal attack vector, as the
> attacker can 'sit back' and let a (legitimate) user trigger the
> issue; hence keeping the footprint for a IDS or WAAS to act on small.
> 
> * Resolvers/systems affected:
> 
> At this point of time the stock resolvers (in combination with the libc
> library) of OSX 10.9 (all versions) and 10.10/R2 are the only known
> standard installations that pass the bash exploit string back and
> up to getnameinfo(). 
> 
> That means that UNpatched systems are vulnerable through this vector
> PRIOR to the bash update documented in http://support.apple.com/kb/DL1769.
> 
> Most other OS-es (e.g. RHEL6, Centos, FreeBSD 7 and up, seem 
> unaffected in their stock install as libc/libresolver and DNS use 
> different escaping mechanisms (octal v.s. decimal).
> 
> We're currently following investing a number of async DNS resolvers
> that are commonly used in DB cache/speed optimising products and
> application level/embedded firewall systems.
> 
> Versions affected: 
> 
> See above CVEs as your primary source.
> 
> * Resolution and Mitigation:
> 
> In addition to the mitigations listed in above CVEs - IDSes and similar 
> systems may be configured to parse DNS traffic in order to spot the 
> offending strings.
> 
> Also note that Apple DL1769 addresses the Bash issue; NOT the vector
> through the resolver. 
> 
> * Reproducing the flaw:
> 
> A simple zone file; such as:
> 
> $TTL 10;
> $ORIGIN in-addr.arpa.
> @ IN SOA ns.boem.wleiden.net dirkx.webweaving.org (
>666; serial
>360 180 3600 1800 ; very short lifespan.
>)
> IN  NS 127.0.0.1
> *   PTR  "() { :;}; echo CVE-2014-6271, CVE-201407169, RDNS" 
> 
> can be used to create an environment in which to test the issue with existing 
> code
> or with the following trivial example:
> 
>#include 
>#include 
>#include 
>#include 
>#include 
>#include 
>#include 
>#include 
> 
>int main(int argc, char ** argv) {
> struct in_addr addr;
> struct sockaddr_in sa;
> char host[1024];
> 
> assert(argc==2);
> assert(inet_aton(argv[1],&addr) == 1);
> 
> sa.sin_family = AF_INET;
> sa.sin_addr = addr;
> 
> assert(0==getnameinfo((struct sockaddr *)&sa, sizeof sa,
>  host, sizeof host, NULL, 0, NI_NAMEREQD));
> 
> printf("Lookup result: %s\n\n", host);
> 
> assert(setenv("REMOTE_HOST",host,1) == 0);
> execl("/bin/bash",NULL);
>}
> 
> 
> Credits and timeline
> 
> The flaw was found and reported by Stephane Chazelas (see CVE-2014-6271
> for details).  Dirk-Willem van Gulik (dirkx(at)webweaving.org) found
> the DNS reverse lookup vector.
> 
> 09-04-2011 first reported.
> 2011, 2014 issue verified on various embedded/firewall/waa

Re: PROXY_WORKER_MAX_NAME_SIZE

[Dirk-Willem van Gulik]

> On 29 Aug 2014, at 21:05, Jim Jagielski  wrote:
> 
> FWIW, this is reported in
> 
>https://issues.apache.org/bugzilla/show_bug.cgi?id=53218
> 
> I was thinking of a dual-approach: Increase PROXY_WORKER_MAX_NAME_SIZE
> and making the truncation of the worker name (s->name) non-fatal
> (but logged at ALERT)...
> 

I've been bitten by this quite a few times as well. And always when you least 
expect it. 

Wondering if it is time to push long names into a uuid or hash; with a 
translation table/db file if needed. 

Dw. 

>> On Aug 29, 2014, at 2:27 PM, Jim Jagielski  wrote:
>> 
>> I'd like to propose that we bump up PROXY_WORKER_MAX_NAME_SIZE
>> again, both in trunk but also allow for backporting to
>> 2.4.x as well.
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: Odd - SSLCipherSuite

[Dirk-Willem van Gulik]

Op 19 mei 2014, om 15:04 heeft Dirk-Willem van Gulik  het 
volgende geschreven:

> Op 17 mei 2014, om 14:15 heeft Dr Stephen Henson 
>  het volgende geschreven:
>> On 14/05/2014 10:23, Dirk-Willem van Gulik wrote:
>>> Now I must be getting rusty - we have in the config file
>>> 
>>> SSLCipherSuite -ALL:ECDHE-RSA-AES256-SHA
>>> SSLProtocol -ALL +TLSv1.1 +TLSv1.2 +SSLv3
>>> 
>>> with the first resolving nicely with
>>> 
>>> openssl ciphers -ALL:ECDHE-RSA-AES256-SHA
>>> 
>>> to just
>>> 
>>> ECDHE-RSA-AES256-SHA
...
>>> So my assumption is that this server will insist on talking above - and =
> 
>>> nothing else.
>>> 
>>> And on the wire - if I observer the Server Hello I see:
>>> 
>>> Secure Sockets Layer
>>>   TLSv1.2 Record Layer: Handshake Protocol: Server Hello
>>> ...
>>>   Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 =
>>> (0xc030)
>>> 
>>> which is sort of what i expect. 
…..
>>> However when I throw 
> 
>>> 
>>> https://www.ssllabs.com/ssltest/analyze.html
>>> 
>>> their analyzer at it - it seems to be quite able to convince the server =
>>> to say hello=92s with
>>> 
>>>SSLv3 Record Layer: Handshake Protocol: Server Hello
>>>   Content Type: Handshake (22)
>>>Version: SSL 3.0 (0x0300)
>>> ...
>>>Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
….
>> 
>> It looks like OpenSSL isn't receiving that cipher string properly or if it is
>> being overridden by something else possible elsewhere in the config file. You
>> can probe individual ciphersuites using s_client like this:
>> 
>> openssl s_client -connect www.hostname.com:443 \
>>  -cipher ECDHE-RSA-AES256-GCM-SHA384
>> 
>> If it isn't supported the connection shouldn't complete.
> 
> Right - yet it does - and matches the suites found by www.ssllabs.com as 
> well. I’ll instrument OpenSSL a bit to see
> what it actually receives and thinks it is doing.
> 
> Perhaps apache manages to confuse some context.

Ok - so OpenSSL is not at fault. It is in apache config land that we confuse 
contexts between
virtualhosts; the ___default__:443, the *:443 and the ‚base’ virtual hosts - 
and I think that this
is almost a ‚must’ as soon as SNI is active. And we cannot really solve it with 
-ALL or !ALL.

Will dig a bit deeper - but my guess is that the ‚best’ solution may well be a 
WARN flag if we
detect an ‚override’ on the same ssl context and/or an INFO flag that shows the 
per VHOST
actual result.

Will puzzle a bit,

Dw

Re: Odd - SSLCipherSuite

[Dirk-Willem van Gulik]

Op 17 mei 2014, om 14:15 heeft Dr Stephen Henson 
 het volgende geschreven:

> On 14/05/2014 10:23, Dirk-Willem van Gulik wrote:
>> Now I must be getting rusty - we have in the config file
>> 
>> SSLCipherSuite -ALL:ECDHE-RSA-AES256-SHA
>> SSLProtocol -ALL +TLSv1.1 +TLSv1.2 +SSLv3
>> 
>> with the first resolving nicely with
>> 
>> openssl ciphers -ALL:ECDHE-RSA-AES256-SHA
>> 
>> to just
>> 
>> ECDHE-RSA-AES256-SHA
>> 
> 
> Unusual syntax though that should work. I'd normally just use the single
> ciphersuite name in the string:
> 
> ECDHE-RSA-AES256-SHA

That still gives us the same results.

> 
>> So my assumption is that this server will insist on talking above - and =
>> nothing else.
>> 
>> And on the wire - if I observer the Server Hello I see:
>> 
>> Secure Sockets Layer
>>   TLSv1.2 Record Layer: Handshake Protocol: Server Hello
>> ...
>>   Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 =
>> (0xc030)
>> 
>> which is sort of what i expect. 
>> 
> 
> I wouldn't expect that as that isn't the single ciphersuite you've specified.

Ok.

>> However when I throw 
>> 
>> https://www.ssllabs.com/ssltest/analyze.html
>> 
>> their analyzer at it - it seems to be quite able to convince the server =
>> to say hello=92s with
>> 
>>SSLv3 Record Layer: Handshake Protocol: Server Hello
>>   Content Type: Handshake (22)
>>Version: SSL 3.0 (0x0300)
>> ...
>>Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
>> 
>> or
>> 
>>   TLSv1.2 Record Layer: Handshake Protocol: Server Hello
>> ...
>>   Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015)
>> 
>> And so on*. I must be missing something very obvious here! Am I
>> misunderstanding SSLCipherSuite or is there something specific about 1.2 
>> which
>> makes certain things mandatory and not under control of SSLCipherSuite? 
>> 
> 
> It looks like OpenSSL isn't receiving that cipher string properly or if it is
> being overridden by something else possible elsewhere in the config file. You
> can probe individual ciphersuites using s_client like this:
> 
> openssl s_client -connect www.hostname.com:443 \
>   -cipher ECDHE-RSA-AES256-GCM-SHA384
> 
> If it isn't supported the connection shouldn't complete.

Right - yet it does - and matches the suites found by www.ssllabs.com as well. 
I’ll instrument OpenSSL a bit to see
what it actually receives and thinks it is doing.

Perhaps apache manages to confuse some context.

Dw.

Re: Odd - SSLCipherSuite

[Dirk-Willem van Gulik]

Op 14 mei 2014, om 19:10 heeft Plüm, Rüdiger, Vodafone Group 
 het volgende geschreven:

> Which Apache version do you use?

Below was with:

Apache/2.4.9 
OpenSSL 1.0.1e-freebsd

but I reverted to that from a patched/hacked build from HEAD while 
investigating the issue. Does this ring a bell?

Dw.


> Von: Dirk-Willem van Gulik [mailto:di...@webweaving.org] 
> Gesendet: Mittwoch, 14. Mai 2014 11:23
> An: dev@httpd.apache.org
> Betreff: Odd - SSLCipherSuite
>  
> Now I must be getting rusty - we have in the config file
> 
>   SSLCipherSuite -ALL:ECDHE-RSA-AES256-SHA
>   SSLProtocol -ALL +TLSv1.1 +TLSv1.2 +SSLv3
> 
> with the first resolving nicely with
> 
>   openssl ciphers -ALL:ECDHE-RSA-AES256-SHA
> 
> to just
> 
>   ECDHE-RSA-AES256-SHA
> 
> So my assumption is that this server will insist on talking above - and =
> nothing else.
> 
> And on the wire - if I observer the Server Hello I see:
> 
>   Secure Sockets Layer
>   TLSv1.2 Record Layer: Handshake Protocol: Server Hello
>   ...
>   Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 =
> (0xc030)
> 
> which is sort of what i expect. 
> 
> However when I throw 
> 
>   https://www.ssllabs.com/ssltest/analyze.html
> 
> their analyzer at it - it seems to be quite able to convince the server =
> to say hello=92s with
> 
>   SSLv3 Record Layer: Handshake Protocol: Server Hello
>   Content Type: Handshake (22)
>   Version: SSL 3.0 (0x0300)
>   ...
>   Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
> 
> or
> 
>TLSv1.2 Record Layer: Handshake Protocol: Server Hello
>   ...
>Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015)
>
> And so on*. I must be missing something very obvious here! Am I  
> misunderstanding SSLCipherSuite or is there something specific about 1.2 
> which makes certain things mandatory and not under control of SSLCipherSuite? 
> 
> Dw.
> 
> 
> 
> 
> * besides Cipher Suite: =
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) 
> Server Hello=92s with 
> 
> Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
>Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
>Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
>Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
>Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
>Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
>Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
>Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
>Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
>Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015)
>Cipher Suite: TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x009a)
>Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
>Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
>Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
>Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
>Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
>Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
>Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
>Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
>Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
>Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
>Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
>Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
>Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
>Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
>Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
>Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
>Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
>Cipher Suite: TLS_RSA_WITH_IDEA_CBC_SHA (0x0007)
>Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
>Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
>Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096)

Odd - SSLCipherSuite

[Dirk-Willem van Gulik]

Now I must be getting rusty - we have in the config file

SSLCipherSuite -ALL:ECDHE-RSA-AES256-SHA
SSLProtocol -ALL +TLSv1.1 +TLSv1.2 +SSLv3

with the first resolving nicely with

openssl ciphers -ALL:ECDHE-RSA-AES256-SHA

to just

ECDHE-RSA-AES256-SHA

So my assumption is that this server will insist on talking above - and =
nothing else.

And on the wire - if I observer the Server Hello I see:

Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Server Hello
...
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 =
(0xc030)

which is sort of what i expect. 

However when I throw 

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

their analyzer at it - it seems to be quite able to convince the server =
to say hello=92s with

SSLv3 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: SSL 3.0 (0x0300)
...
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

or

   TLSv1.2 Record Layer: Handshake Protocol: Server Hello
...
   Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015)
   
And so on*. I must be missing something very obvious here! Am I  
misunderstanding SSLCipherSuite or is there something specific about 1.2 which 
makes certain things mandatory and not under control of SSLCipherSuite? 

Dw.




* besides Cipher Suite: =
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) 
Server Hello=92s with 

Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
   Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
   Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
   Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
   Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
   Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
   Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
   Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
   Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
   Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015)
   Cipher Suite: TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x009a)
   Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
   Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
   Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
   Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
   Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
   Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
   Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
   Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
   Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
   Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
   Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
   Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
   Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
   Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
   Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
   Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
   Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
   Cipher Suite: TLS_RSA_WITH_IDEA_CBC_SHA (0x0007)
   Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
   Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
   Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096)

Re: AuthBasicProvider ssl-client-cert?

[Dirk-Willem van Gulik]

Op 21 jul. 2013, om 20:58 heeft Graham Leggett  het volgende 
geschreven:

> On 17 Jul 2013, at 4:44 PM, Eric Covener  wrote:
> 
>> All of the client-cert-as-basic-auth-substitute mechanisms we have
>> require you to check the dummy password with a "real"
>> authbasicprovider.

That is not quite the case; you can avoid this with Anon and Authoritative; but 
conceptually that is as 'unclean'.

..
>> I think I need this to deprecate a proprietary module, and I don't
>> want to replace it with a proprietary (albeit simple)
>> AuthBasicProvider.
> 
> +1.
> 
> I would add this to mod_ssl though, rather than trying to make something like 
> mod_auth_basic aware of this.

Agreed - this is something that should sit with mod_ssl - or be a side module 
to mod_ssl.

Fixing/adding this would probably mean also addressing some of the CA chain 
lax-ness we currently have  - and have three (four) very distinct chains; one 
for the server itself & intermediates; one for the proxy and what it wants it 
accepts and one for the proxy it identifies as; and one for the client and what 
intermediates it recognises.

That may not be quite backward compatible - but IMHO worth breaking a few 
configs.

Dw.

Re: breach attack

[Dirk-Willem van Gulik]

Op 12 aug. 2013, om 01:35 heeft Eric Covener  het volgende 
geschreven:

> 
> > What do you think of including a header? Is there a way to find out
> > from the encrypted traffic where the header ends and where the body
> > starts?
> 
> For a typical request they are in separate SSL records and someone running a 
> packet capture can tell when the headers or body has grown.  We could arrange 
> for the headers to always span an SSL record, and put a variable length one 
> at the bottom  -- but that only helps if the secret and request data are in 
> the first frame.
Not sure - I am fairly sure we nicely cut on headers - and have the (SSL) 
packets go out at or very near the end of the header. 

So I guess we'd intentionally would have to sub-optimize this somewhat - or 
uses some default chunked/mime-type boundary trickery outside the traditional 
header instead.

Dw.

Re: breach attack

[Dirk-Willem van Gulik]

Op 10 aug. 2013, om 21:35 heeft Reindl Harald  het 
volgende geschreven:
> 
> IMHO that is all the wrong train
> 
> "victim's browser to visit the targeted website thousands of times"
> for me says clearly that a proper server with rate-controls based
> on iptable sor a firewall in front of the machine would stop this
> and honestly these days i would not connect any production server
> without rate-controls to the world wide web
> 
> so i am strictly against mangle in the procotol and risk making
> mod_defalte less effective, protections aginst such attacks do
> not belong in the application layer

A couple of years ago - I would have wholeheartedly agreed with you.

However the world is changing. And several things combined make the assumption 
that such vigilance is likely (or even possible) no longer a safe one.

At the higher layers - developers work increasingly with abstraction layers, 
languages and frameworks which are far removed from HTTP; and which no longer 
require the developer to look at things like field completion, sessions and 
ajax-dynamic population of fields, gradual disclosure and what not at the GET 
level. Instead some (js) library or framework is used which just does it.

So technically it is no longer realistic for the average (or every crack) 
programmer to tell you what GETs to normally expect. And organizationally it is 
totally unrealistic; there are simply too few incentives for that information 
to flow. That 'layer' of the org is not paid/expected to care.

Increasingly the http layer moves to the very bottom of the stack - well out of 
sight; tended to by people very far (and commonly at arms length) removed from 
the web product. It may even be mostly in some sort of proxy/pass-through type 
of mode - where the ops people have no real idea as to what request goes to 
what app - and the volume is such that only automated tools help make sense of 
it.

Wether we like it or not - Apache is now commonly deployed in that world.

So our 'new' users can fairly expect us to tune apache to that sort of 'blind' 
and 'bulky' deployments. So I think it somewhat behooves us to have options to 
mangle the protocol where and when needed - and focus on these in 'bulk and 
blind' modes.

Dw.

Re: breach attack

[Dirk-Willem van Gulik]

On 10 Aug 2013, at 18:14, "Steinar H. Gunderson"  wrote:

> On Sat, Aug 10, 2013 at 06:11:09PM +0200, Dirk-Willem van Gulik wrote:
>> I'd keep in mind that compression is simply an amplifier for this type of
>> attack. It makes the approach more effective. But it is not essential; when
>> you have in essence a largely known plaintext surrounding a short secret
>> and an oracle. And the latter is not going to go away - current dominant
>> site development models will make this worse; as do current operational
>> models w.r.t. to picking such up early.
> 
> Wait, what's the oracle if there's no compression?


As as ultimately before - the origin server (and/or the traffic you compare it 
to). Granted - doing this raw is not that feasible for large key lengths - but 
even some slight weakness elsewhere (could be as silly as a render/timing 
change in the browser) will help.

Dw.

Re: breach attack

[Dirk-Willem van Gulik]

On 10 Aug 2013, at 00:37, Eric Covener  wrote:

> On Fri, Aug 9, 2013 at 5:24 PM, Steinar H. Gunderson
>  wrote:
>> On Tue, Aug 06, 2013 at 01:32:00PM -0400, Eric Covener wrote:
>>> Another option in this neighborhood is small/varying deflate blocks.
>>> But that probably limits the usefulness of deflate to the same extent
>>> that it helps.  The idea is to make it less likely that the user input
>>> and secret get compressed together.
>> 
>> It would be interesting to see how feasible “barriers” in mod_deflate would
>> be. E.g., if my application outputs
>> 
>>  > DEFLATE_BARRIER_END>
>> 
>> maybe mod_deflate could be taught not to compress the parts in-between.
> 
> For this attack, it would be enough to compress that section by itself
> -- a barrier between the reflected user input and the "secret".

I'd keep in mind that compression is simply an amplifier for this type of 
attack. It makes the approach more effective. But it is not essential; when you 
have in essence a largely known plaintext surrounding a short secret and an 
oracle. And the latter is not going to go away - current dominant site 
development models will make this worse; as do current operational models 
w.r.t. to picking such up early.

So the only fundamental thing we can do (i.e. if we want to go beyond guessing 
(future) browser and developer introduced vulnerabilities at higher layers) is 
a wee bit of padding/random*-cruft insertion in key places. Perhaps even doing 
so by default.

And whilst on this topic - may be good to also consider a slow migration away 
from RSA to at least DH and perhaps ECC where possible as our 'default's.

Dw.

*: or very pseudo - as not to make it simply a nop in statistics.

Re: DOS-Protection: RequestReadTimeout-like option missing

[Dirk-Willem van Gulik]

On 11 May 2013, at 20:26, Reindl Harald  wrote:

> after the connection is established and in case of connect
> you have already passed the TCP transmissions and kernel
> settings like
> 
> net.ipv4.tcp_fin_timeout = 5
> net.ipv4.tcp_retries1 = 5
> net.ipv4.tcp_syn_retries = 5
> net.ipv4.tcp_synack_retries = 5

The way I usually deal with this is three fold - and I think that it a) behoves 
apache/traffic servr to allow admins to configure this in widely varying ways 
while b) have somewhat sane middle of the road settings.

-   Use *bsd/linux accept filters or similar just in front to 
not kick off too much of the http stack without having the
client invest in sending a few decent bytes and a bit of
TCP stack state.

In practice, with mobile clients, I've found it hard to
be too strict. Many seconds may pass before a long haul
connection has its 'GET' sent.

Above tcp settings are appropriate for certain modern
internet sites in modernly wired countries - but would
not see them as universally good.

So not much we should do I guess - beyond a couple
of best practice hints covering 2 or 3 widely
different scenario's.

-   Try to avoid too much code waking up to deal with the
GET, and subsequently, too much code from lingering
around after the entire reply is generated just to
'sent out' this reply byte by byte. Which often is as
simple as a small proxy in front.

Likewise - this is not universally good - as there are
plenty of situations where local skill & incident response
patterns would cause such an approach to make things
less (instead of more) reliable.

So again - we can just suggest some best pratice.

-   Hand off (or kill) seriously lengthy things to a special
polling/async (i.e. single thread/process 'ab' select/poll 
style with linked lists buffer/pointers) process. E.g.
using things like inter process file descriptor passing
or some N-Path thing at TCP level.

Which is again - just one of the many ways to approach
things. And again - lots of variants possible.

So am doubtful if this sort of knowledge should be part of the default. 

Think that those settings should be fairly conservative - designed to work in a 
wide range of settings. 

Even if that means you can hog resources remotely with relative ease - as it is 
hard to 
know ahead of time if this is a enterprise-server sending large java generated 
blobs to people on a local LAN or a small server doing short ajax-y replies to 
mobile clients with 10's of seconds idleness in lots of parallel connections.

Just my 2 pence. 

:-) 
-- Dw.




smime.p7s
Description: S/MIME cryptographic signature

Re: URL scanning by bots

[Dirk-Willem van Gulik]

On 3 mei 2013, at 10:55, Marian Marinov  wrote:
> 
> If Apache by default delays 404s, this may have some effect in the first 
> month or two after the release of this change. But then the the botnet 
> writers will learn and update their software.
> I do believe that these guys are monitoring mailing lists like these or at 
> least reading the change logs of the most popular web servers.
> So, I believe that such change would have a very limited impact on the whole 
> Internet or at least will be combated fairly easy.

FWIIW - the same sentiments where expressed when 'greylisting[1]' in SMTP came 
in vogue. For small relays (speaking just from personal experience and from the 
vantage of my own private tiny MTA's) that has however not been the case. 
Greylisting did dampen things significantly - and the effect lasts to this day.

But agreed - I think it is important to deal with this issue differently that 
with the overload issue.

Dw.

1: http://en.wikipedia.org/wiki/Greylisting

smime.p7s
Description: S/MIME cryptographic signature

Re: URL scanning by bots

[Dirk-Willem van Gulik]

I think we're mixing three issues

1)  Prevent Starvation.

protecting a server from server side/machine starvation (i.e. running 
out of file descriptors, sockets, mbuf's, whatever).

So here you are in the domain where there is no argument in terms of 
protocol violation/bad citizens; there simply
is no resource - some something gotta give.

So in this case - having hard cap's on certain things is helpful. And 
if for certain setups the current MaxXXX are
not good enough (e.g. to keep a slowlaris in check as per normal modus 
operandi) - then that needs to be fixed.

IMHO this is something dear to me, as a developer. And it should be 
fixed 'by default'. I.e. a normal configured
apache should behave sensible in situations like this.

And this is 'alway'  the case.

There is a special case of this - and that is of sites which to some 
extend have shot themselves in the foot
with a 'bad' architecture; where somehow some application/language 
environment has a tendency to
eat rather a lot of resources; and leave (too little) to the httpd 
daemon.

2)  Dealing with Noise

Generally observing that on a quiet server some 30-60% (speaking for 
myself here) of your 'load' is caused
by dubious/robotic stuff which does not benefit 'you' as the site owner 
with a desire to be found/public directly
or even indirectly (e.g. like a webcrawler of a search engine would do).

And this then begs the question - what can I, as a site owner (rather 
than a developer) configure - even if
that means that I 'break the internet' a bit. 

And this is something you decide on a per server basis; for long 
periods of time.

3)  Dealing with Attacks.

Dealing with specific attempts to overload a server one way or the 
other; with the intention to lock
other users out.

For most of us, and unlike above two examples, a specific situation; 
and one which probably last
relatively short (days, weeks).

And for which you are willing to do fairly draconian things - even if 
that significantly breaks normal
internet standard behaviour.

Would be useful to discuss each separately. As I do agree with some of the 
posters that apache is (no longer)
that strong* in area 1 and 3. And some modernisation may do wonders,

Thanks,

Dw

*: i.e. meaning that one tends to do highly specific things when dealing with 
issues like that; and while
   generally (very) effective - they are not part of core apache lore & default 
config.

smime.p7s
Description: S/MIME cryptographic signature

Re: URL scanning by bots

[Dirk-Willem van Gulik]

On 1 mei 2013, at 13:31, Graham Leggett  wrote:
> 
> The evidence was just explained - a bot that does not get an answer quick 
> enough gives up and looks elsewhere.
> The key words are "looks elsewhere".


For what it is worth - I've been experimenting with this (up till about 6 
months ago) on a machine of mine. Having the 200, 403, 404, 500 etc determined 
by an entirely unscientific 'modulo' of the IP address. Both on the main URL as 
well as on a few PHP/plesk hole URLs. And have ignored/behaved normal for any 
source IP that has (ever) fetched robot.txt from the same IP masked by the 
first 20 bits.

That showed that bot's indeed slowdown/do-not-come back so soon if you give 
them a 403 or similar - but I saw no differences as to which non 200 you give 
them (not tried slow reply or no reply). Do note though that I was focusing on 
naughty non-robot.txt fetching bots.

Dw





smime.p7s
Description: S/MIME cryptographic signature

Re: Small things to do

[Dirk-WIllem van Gulik]

On 8 Nov 2011, at 23:03, Daniel Ruggeri wrote:

> On 11/8/2011 3:10 PM, Stefan Fritsch wrote:
> >   * mod_ssl's proxy support only allows one proxy client certificate per
> > frontend virtual host. Lift this restriction.
> > jim sez: Why a blocker?, pgollucci +1 jim
> > wrowe asks: what's the API change required?
> 
> I'm not sure I understand this one... does anyone have the history to
> elaborate?
> 

Three things really - in order of priority:

-   Specify a specific client cert per proxy-pass or other 

smime.p7s
Description: S/MIME cryptographic signature

Re: Another regression regarding byteranges

[Dirk-Willem van Gulik]

On 1 Sep 2011, at 13:33, Jim Jagielski wrote:

> 
> On Sep 1, 2011, at 6:31 AM, Plüm, Rüdiger, VF-Group wrote:
>> I already fixed that in trunk.
>> I think this regression justifies another release for 2.2.x. But IMHO we 
>> should wait at least until
>> mid next week to see if other regressions come thru and hit them all with a 
>> 2.2.21.
>> 
> 
> +1
> 

Ok - so this makes it sound we really should get the advisory out. Shall I 
update it with some caveats and stay tuned - but still make it FINAL ?

Or should we make this an update - and not declare final victory ?

Dw.

Re: Next update

[Dirk-Willem van Gulik]

On 1 Sep 2011, at 12:06, Ben Laurie wrote:

> On Wed, Aug 31, 2011 at 9:03 PM, Dirk-WIllem van Gulik
>  wrote:
>> Suggestion for
>> 
>>http://people.apache.org/~dirkx/CVE-2011-3192.txt
> 
> You probably mean "deprecated" not "desecrated", amusing though that is.
> 
Darn Functional MRI - them spell checkers are getting scarily good at reading 
my mind !

Thanks Ben,

Dw. 

Re: Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x (CVE-2011-3192)

[Dirk-WIllem van Gulik]

Folks,

See below - for the 1.3 discussion - that suggest we should take it a notch 
down:

On 31 Aug 2011, at 22:35, Munechika Sumikawa wrote:

 We're currently discussing this - and will propably adjust the
 announcement a bit. It is vulnerable in that it can suddenly take a
 lot more CPU, memory and resources when 'attacked'. And the response
 is worse than pure linear. But unlike 2.0 and 2.2 it does not
 exploded as exponential. So at this point I am expecting us to
 conclude that 1.3 is 'as affected' as most other servers
 implementing this protocol; not due to a fault in the code - but
 more to a fault in the protocol desgin.
 
 Does that make sense ?
>>> 
>>> Let me confirm the code.  Apache 1.3 allocates only several bytes per
>>> each "byte-range" to record first-pos and last-pos.  And the memory is
>>> released immediately after the HTTP session is disconnected.  Thus,
>>> it's impossible a cracker succeed to DoS 1.3x server with the paranoia
>>> range header.  Am I correct?
>>> 
>>> If so, IMO Apache 1.3's behavior should be normal case.  More
>>> complicated pattern based on the designed protocol eat up more
>>> resources than simpler pattern.  That always happens in any protocols.
>>> (e.g. IP fragmentation)
>>> 
>>> I think it's stll in scope of "linear" even though it's not "pure
>>> linear".

Which makes good sense. And looking at the default 1.3 configs on the standard 
platforms of that time - it is indeed not really apache which is at fault.

Dw.

vote for FINAL announce

[Dirk-WIllem van Gulik]

On 31 Aug 2011, at 21:07, Dirk-WIllem van Gulik wrote:

>>  http://people.apache.org/~dirkx/CVE-2011-3192.txt

Off to bed now. If there is consensus we are 'done' then a vote on either of 
these options would be of use

1   as above

2   as above but with complete reversal of the 1.3 situation - state it is 
totally not affected (i.e. when configure right).

3   as above - but with a large caveat that we're not yet happy with this - 
follow this wiki page and keep an eye out for the release notes of the next 
releases.

Aiming at 1000Z tomorrow - as that gives folks in big companies a lot of 
planning room - and is not yet hitting the 
friday-thou-shall-not-break-things-before-the-weekend.

Thanks,

Dw.

Re: Next update

[Dirk-WIllem van Gulik]

On 31 Aug 2011, at 21:03, Dirk-WIllem van Gulik wrote:

> Suggestion for
> 
>   http://people.apache.org/~dirkx/CVE-2011-3192.txt
> 
> to be sent to announce and the usual security places.
> 
> ->Comments on weaken/strenghten 1.3 text
> 
>   Happy to completely recant that it was vulnerable. Or happy to keep a 
> bit of a warning in there.
> 
> ->Lots of small tweaks.
> 
> ->Do we leave the 200/206 chunked/full range caveats in - or is that no 
> longer the case ?
> 
> Thanks,

Ah - before I forget - also fine to not do it this heavy handed - but to sent 
Jim his message to users/devs@ to these security places as well.

But am slightly biased to towards an advisory of this size - as it helps admins 
in large organizations negotiate priorities with their ops teams, bosses and 
others.

Dw.

Re: Next update

[Dirk-WIllem van Gulik]

Suggestion for

http://people.apache.org/~dirkx/CVE-2011-3192.txt

to be sent to announce and the usual security places.

->  Comments on weaken/strenghten 1.3 text

Happy to completely recant that it was vulnerable. Or happy to keep a 
bit of a warning in there.

->  Lots of small tweaks.

->  Do we leave the 200/206 chunked/full range caveats in - or is that no 
longer the case ?

Thanks,

Dw.

Re: Next update

[Dirk-WIllem van Gulik]

On 26 Aug 2011, at 18:05, William A. Rowe Jr. wrote:

> On 8/26/2011 11:41 AM, Eric Covener wrote:
>> Should we bump the "5"'s in the draft advisory and/or code to a more
>> liberal #?  At the very least for the 2.0 rewrite solution that will
>> return forbidden instead of full content?
> 
> Can we please avoid sending more advisories without a canonical link
> to a wiki recommendations/discussion/observations page?  As admins have
> already adopted the 5's, they are in the best position to tell us what
> broke, based on feedback from their audience.
> 
> I'll start one shortly.

URL ?

Dw.

Re: Next update

[Dirk-WIllem van Gulik]

On 31 Aug 2011, at 18:20, William A. Rowe Jr. wrote:

> Note some additional improvements for a 'final' update 3 advisory…

Ack!  Draft coming in half an hour or so,

Dw.

Wrapup -- Was: 2.2 approach for byterange?

[Dirk-WIllem van Gulik]

Folks,

How do we wrap this up in what remains of the (US) day ? 

I can have ready a final draft or a 'more mitigation' draft  - of the stay 
tuned type. 

Since Advisory update-2 I gotten about 5 emails with helpful (but small) 
improvements for what we have; 3 with some detailed feedback - and a lot of 
reports that the fixes are good enough for most. But nothing major.

So the only reason to sent out a update rather than a final would be that we 
expect the final one to be 24+ hours -- OR if we expect the final one to be 
hard for admins to roll (which we have no indication of).

Correct ?

What are people their thoughts ? Fair to assume we can have in the next 6 to 12 
hours:

-   Patch for 2.2 well tested

-   Backport for 2.0 - ideally well tested too 

Or do we need to roll a complete version (guess not) ? Any verbiage to include 
on this fix not being the final one (IMHO no - IETF pointer is good enough).

Who is in the right timezone to carry the ball the last few meters over the 
finish line?

Thanks,

Dw

Re: svn commit: r1162560 - /httpd/httpd/trunk/modules/http/byterange_filter.c

[Dirk-Willem van Gulik]

On 28 Aug 2011, at 18:12, rpl...@apache.org wrote:

> URL: http://svn.apache.org/viewvc?rev=1162560&view=rev
> Log:
> * Silence compiler warning

> +apr_off_t pofft = 0;


This may have been more than that - it fixes my testcase on FreeBSD with all 
optimizing set to max (OSX and Ubuntu where already fine).

Dw.

Re: Next update

[Dirk-Willem van Gulik]

On 26 aug. 2011, at 18:35, Guenter Knauf wrote:

> Hi Dirk,
> Am 26.08.2011 12:44, schrieb Dirk-Willem van Gulik:
>> 4) Deploy a Range header count module as a temporary stopgap measure:
>> 
>>http://people.apache.org/~dirkx/mod_rangecnt.c
> you have a c&p error for the 1.3.x part:
> 
> --- mod_rangecnt.c.orig Fri Aug 26 18:30:08 2011
> +++ mod_rangecnt.c  Fri Aug 26 18:32:21 2011
> @@ -104,7 +104,7 @@
> }
> 
> #ifndef AP_MODULE_DECLARE_DATA
> -module MODULE_VAR_EXPORT usertrack_module = {
> +module MODULE_VAR_EXPORT rangecnt_module = {

Fixed. And thanks to a weird testing quirck - this actually worked (mod user 
track probably did not :) ). 

Dw.

Advisory improvement

[Dirk-Willem van Gulik]

From the Full Disclosure list. Does anyone have time to confirm this 
improvement.

On 26 Aug 2011, at 12:09, Carlos Alberto Lopez Perez wrote:
> RewriteEngine on
> RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC,OR]
> RewriteCond %{HTTP:request-range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC]
> RewriteRule .* - [F]
> 
> Because if you don't specify the [OR] apache will combine the rules
> making an AND (and you don't want this!).
> 
> Also use NC=(nocase) to prevent the attacker upper casing "bytes="
> (don't know if it will work.. but just to prevent)

Pretty Please !

Thanks,

Dw.

Re: Next update

[Dirk-Willem van Gulik]

On 26 aug. 2011, at 10:47, Dirk-Willem van Gulik wrote:

> Folks - as we're not quit there yet - I want to do sent out an updated 
> advisory at 11:00 UTC. We have enough new information and extra mitigations. 
> Will post the draft(s) to security@ this time.

Apologies for the rush and blindsiding some people. But the friendly folks out 
there had finally cottoned on my accidental comment in the module code that 
request-range was equally affected. 

So I thought it appropriate to release the advisory as is; with all the regex 
improvements and other fixes.

Thanks.

Dw.


Apache HTTPD Security ADVISORY
==
  UPDATE 2

Title:   Range header DoS vulnerability Apache HTTPD 1.3/2.x

CVE: CVE-2011-3192
Last Change: 20110826 1030Z
Date:20110824 1600Z
Product: Apache HTTPD Web Server
Versions:Apache 1.3 all versions, Apache 2 all versions

Changes since last update
=
In addition to the 'Range' header - the 'Range-Request' header is equally
affected. Furthermore various vendor updates, improved regexes (speed and
accommodating a different and new attack pattern).

Description:


A denial of service vulnerability has been found in the way the multiple 
overlapping ranges are handled by the Apache HTTPD server:

   http://seclists.org/fulldisclosure/2011/Aug/175 

An attack tool is circulating in the wild. Active use of this tool has 
been observed.

The attack can be done remotely and with a modest number of requests can 
cause very significant memory and CPU usage on the server. 

The default Apache HTTPD installation is vulnerable.

There is currently no patch/new version of Apache HTTPD which fixes this 
vulnerability. This advisory will be updated when a long term fix 
is available. 

A full fix is expected in the next 24 hours. 

Background and the 2007 report
==

There are two aspects to this vulnerability. One is new, is Apache specific; 
and resolved with this server side fix. The other issue is fundamentally a 
protocol design issue dating back to 2007:

http://seclists.org/bugtraq/2007/Jan/83 

The contemporary interpretation of the HTTP protocol (currently) requires a 
server to return multiple (overlapping) ranges; in the order requested. This 
means that one can request a very large range (e.g. from byte 0- to the end) 
100's of times in a single request. 

Being able to do so is an issue for (probably all) webservers and currently 
subject of an IETF discussion to change the protocol:

http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311

This advisory details a problem with how Apache httpd and its so called 
internal 'bucket brigades' deal with serving such "valid" request. The
problem is that currently such requests internally explode into 100's of 
large fetches, all of which are kept in memory in an inefficient way. This
is being addressed in two ways. By making things more efficient. And by 
weeding out or simplifying requests deemed too unwieldy.

Mitigation:
===

There are several immediate options to mitigate this issue until a full fix 
is available. Below examples handle both the 'Range' and the legacy
'Request-Range' with various levels of care. 

Note that 'Request-Range' is a legacy name dating back to Netscape Navigator 
2-3 and MSIE 3. Depending on your user community - it is likely that you
can use option '3' safely for this older 'Request-Range'.

1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
 either ignore the Range: header or reject the request.

 Option 1: (Apache 2.2)

# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (?:,.*?){5,5} bad-range=1
RequestHeader unset Range env=bad-range

# We always drop Request-Range; as this is a legacy
# dating back to MSIE3 and Netscape 2 and 3.
RequestHeader unset Request-Range

# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
CustomLog logs/range-CVE-2011-3192.log common env=bad-req-range

 Above may not work for all configurations. In particular situations
 mod_cache and (language) modules may act before the 'unset'
 is executed upon during the 'fixup' phase.

 Option 2: (Pre 2.2 and 1.3)

# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(bytes=[^,]+(,[^,]+){0,4}$|^$)
# RewriteCond %{HTTP:request-range} !(bytes=[^,]+(?:,[^,]+){0,4}$|^$)
RewriteRule .* - [F]

# We always drop Request-Range; as this is a legacy
# dating back to MSIE3 and Netscape 2 and 3.
RequestHeader unset Request-Range

 The number 5 is arbitrary. Several

Next update

[Dirk-Willem van Gulik]

Folks - as we're not quit there yet - I want to do sent out an updated advisory 
at 11:00 UTC. We have enough new information and extra mitigations. Will post 
the draft(s) to security@ this time.

Secondly - I got below updates to the regex-es; to optimise the pcre 
expressions and remove the exhaustive match:

from
   SetEnvIf Range (,.*?){5,} bad-range=1
to
   SetEnvIf Range (?:,.*?){5,} bad-range=1

from:
   RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
to:
   RewriteCond %{HTTP:range} !(?:^bytes=[^,]+(?:,[^,]+){0,4}$|^$)

Please pipe up if you see issues with those,

Thanks

Dw.

PS: Committers - if you are not subscribed to security@ - now is a good time :)

CVE-2011-3192 - NeXT update ?

[Dirk-WIllem van Gulik]

Folks,

What is wisdom? We have an updated version at 
people.apache.org/CVE-2011-3192.txt. 

i'd say, let's send this of day if we expect the full patch to take another 24+ 
hours. As there is a need for the i proved mitigations  And otherwise skip it 
and go to final ASAP?

What is your take ?

Thanks,

Dw.
-- 
Dirk-Willem van Gulik.

Re: Truly minor inconsistency in mod_rangecnt.c

[Dirk-Willem van Gulik]

On 25 Aug 2011, at 15:53, Tom Evans wrote:

> I wasn't sure whether to mail this in, it is inconsequential; the
> module is supposed to count the number of ranges, but it actually
> counts the number of commas between ranges, leading to an off-by-one.
> IE, a request with 6 ranges would not be rejected, where as the code
> has #define MAXRANGEHEADERS (5).

Yup - spot on - that is indeed a bug. And actually - with what we know
now - that number should probably be a 100 or so.

> Its truly minor, but made my test tool to determine whether a server
> is vulnerable to give some false positives, as it was sending 5 ranges
> and expecting a 417.

But lets fix it fixed :)

Thanks!

Dw.

Re: Fixing Ranges

[Dirk-Willem van Gulik]

On 25 Aug 2011, at 17:45, Greg Ames wrote:

> On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski  wrote:
> Now that the memory utilz is being fixed, we need to determine
> what sort of usage we want to allow… I'm guessing that people
> are ok with http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311
> as the guiding spec?
> 
> I'm no longer convinced that we *need* to merge/optimize the Range header.  
> Stefan's fix to the brigade plumbing has converted O(N^2) memory + CPU use 
> into something scalable.  

Same feeling here. BUT that is based on the FreeBSD platform I care about. And 
we have noticed earlier that Ubuntu (which its default commit pattern in the 
vm) behaves very differently. 

So is it fair to assume this reasoning holds across the board -- or should we 
get some very explicit +1's on this appraoch from key linux, windows and what 
not users ?

Dw

Re: Fixing Ranges

[Dirk-Willem van Gulik]

On 25 Aug 2011, at 15:48, Plüm, Rüdiger, VF-Group wrote:

> +1 for 2.3, -0 for 2.2. I guess for 2.2 we should only detect "misuse" (the 
> definition of misuse
> needs to configurable) and reply with a 200 if misuse is detected.

Ok - given the patch a good test - and actually - am not sure we need even that 
(much) abuse detection. 

I find it darn hard to kill the server now; and would almost say that we can 
leave it as is. And PERHAPS have an optional cap on the number of ranges (Set 
at unlimited by default -leaving it to LimitRequestFieldSize to cap it off at 
effectively some 1200-1500).

Thanks

Dw

Re: Fixing Ranges

[Dirk-Willem van Gulik]

On 25 Aug 2011, at 12:40, Jim Jagielski wrote:

> Tested and this does appear to both address the DoS as well as
> reduce memory usage for "excessive" range requests…
> 
> +1 for adding this no matter what.

Yup - same here. Makes PDF serving a heck of a lot better too.

Dw.

> 
> On Aug 24, 2011, at 7:38 PM, Stefan Fritsch wrote:
> 
> > On Thursday 25 August 2011, Greg Ames wrote:
> >> On Wed, Aug 24, 2011 at 5:16 PM, Stefan Fritsch 
> > wrote:
> >>> I have another idea: Instead of using apr_brigade_partition write
> >>> a new function ap_brigade_copy_part that leaves the original
> >>> brigade untouched. It would copy the necessary buckets to a new
> >>> brigade and then split the first and last of those copied
> >>> buckets as necessary and destroy the excess buckets. AFAICS,
> >>> this would reduce the quadratic growth into linear. Do you think
> >>> that would solve our problems?
> >>
> >> How does apr_brigade_partition contribute to quadratic growth?
> >> Does the original brigade end up with a lot of one byte buckets?
> >
> > Yes, it splits the buckets in the original brigade, creating up to two
> > new buckets for every range. These split one-byte buckets are then
> > copied again for each of the subsequent ranges.
> >
> > The attached PoC patch does not change the original brigade and seems
> > to fix the DoS for me. It needs some more work and some review for
> > integer overflows, though. (apr_brigade_partition does some
> > interesting things there).
> > 
> 
> 

Next update on CVE-2011-3192

[Dirk-Willem van Gulik]

I am keeping a draft at

http://people.apache.org/~dirkx/CVE-2011-3192.txt

Changes since last are:

-   version ranges more specific
-   vendor information added
-   backgrounder on relation to 2007 issues (see below to ensure I got this 
right).

I suggest we sent this out late Z time today (i.e. end of working day US) _if_ 
1) it is likely that we do not have a firm timeline for the full fix and 2) we 
have a bit more to add. Otherwise we skip to a final update with the fixing 
instructions for 2.0 and 2.2

Feedback welcome,

Thanks,

Dw.

Re: Fixing Ranges

[Dirk-Willem van Gulik]

On 24 Aug 2011, at 22:16, Stefan Fritsch wrote:

> I have another idea: Instead of using apr_brigade_partition write a
> new function ap_brigade_copy_part that leaves the original brigade
> untouched. It would copy the necessary buckets to a new brigade and
> then split the first and last of those copied buckets as necessary and
> destroy the excess buckets. AFAICS, this would reduce the quadratic
> growth into linear. Do you think that would solve our problems?

This looks really rather need - it seems to tackle the core issue - that of 
memory; and it also makes it better for legitimate request with many ranges in 
it (while I never noticed before - going back and looking at them - them PDF 
requests do take a lot of memory).

Dw.

Re: Final draft / CVE-2011-3192

[Dirk-Willem van Gulik]

Thanks. Added to the interim draft update.

Dw.

On 25 Aug 2011, at 06:36, Steffen wrote:

> For Mitigation of Apache Range Header DoS Attack with mod_security, see
> also:
> 
> http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html
> 
> 
> - Original Message -
> From: "Dirk-Willem van Gulik" 
> Newsgroups: gmane.comp.apache.devel
> To: ; 
> Sent: Wednesday, August 24, 2011 5:34 PM
> Subject: Final draft / CVE-2011-3192
> 
> 
> Thanks for all the help. All fixes included. Below will go out to announce
> at the top of the hour - unless I see a veto.
> 
> Dw.
> 
> 
> 
> 
> Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
>   Apache HTTPD Security ADVISORY
> 
> Date: 20110824 1600Z
> Product:  Apache HTTPD Web Server
> Versions: Apache 1.3 all versions, Apache 2 all versions
> 
> Description:
> 
> 
> A denial of service vulnerability has been found in the way the multiple
> overlapping ranges are handled by the Apache HTTPD server:
> 
>  http://seclists.org/fulldisclosure/2011/Aug/175
> 
> An attack tool is circulating in the wild. Active use of this tools has
> been observed.
> 
> The attack can be done remotely and with a modest number of requests can
> cause very significant memory and CPU usage on the server.
> 
> The default Apache HTTPD installation is vulnerable.
> 
> There is currently no patch/new version of Apache HTTPD which fixes this
> vulnerability. This advisory will be updated when a long term fix
> is available.
> 
> A full fix is expected in the next 48 hours.
> 
> Mitigation:
> 
> 
> However there are several immediate options to mitigate this issue until
> that time.
> 
> 1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
>either ignore the Range: header or reject the request.
> 
>Option 1: (Apache 2.0 and 2.2)
> 
>   # drop Range header when more than 5 ranges.
>   # CVE-2011-3192
>   SetEnvIf Range (,.*?){5,} bad-range=1
>   RequestHeader unset Range env=bad-range
> 
>   # optional logging.
>   CustomLog logs/range-CVE-2011-3192.log common env=bad-range
> 
>Option 2: (Also for Apache 1.3)
> 
>   # Reject request when more than 5 ranges in the Range: header.
>   # CVE-2011-3192
>   #
>   RewriteEngine on
>   RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
>   RewriteRule .* - [F]
> 
>The number 5 is arbitrary. Several 10's should not be an issue and may be
>required for sites which for example serve PDFs to very high end eReaders
>or use things such complex http based video streaming.
> 
> 2) Limit the size of the request field to a few hundred bytes. Note that
> while
>this keeps the offending Range header short - it may break other headers;
>such as sizeable cookies or security fields.
> 
>   LimitRequestFieldSize 200
> 
>Note that as the attack evolves in the field you are likely to have
>to further limit this and/or impose other LimitRequestFields limits.
> 
>See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
> 
> 3) Use mod_headers to completely dis-allow the use of Range headers:
> 
>   RequestHeader unset Range
> 
>Note that this may break certain clients - such as those used for
>e-Readers and progressive/http-streaming video.
> 
> 4) Deploy a Range header count module as a temporary stopgap measure:
> 
>  http://people.apache.org/~dirkx/mod_rangecnt.c
> 
>Precompiled binaries for some platforms are available at:
> 
> http://people.apache.org/~dirkx/BINARIES.txt
> 
> 5) Apply any of the current patches under discussion - such as:
> 
>
> http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e
> 
> Actions:
> 
> 
> However there are several immediate options to mitigate this issue until
> that time.
> 
> 1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
>either ignore the Range: header or reject the request.
> 
>Option 1: (Apache 2.0 and 2.2)
> 
>   # drop Range header when more than 5 ranges.
>   # CVE-2011-3192
>   SetEnvIf Range (,.*?){5,} bad-range=1
>   RequestHeader unset Range env=bad-range
> 
>   # optional logging.
>   CustomLog logs/range-CVE-2011-3192.log common env=bad-range
> 
>Option 2: (Also for Apache 1.3)
> 
>   # Reject request when

Re: DoS with mod_deflate & range requests

[Dirk-WIllem van Gulik]

On 24 Aug 2011, at 21:39, Greg Ames wrote:

> On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski  wrote:
> 
> >
> > If we only merge adjacent ascending ranges, then it seems like an attacker 
> > could just craft a header where the ranges jump around and dodge our fix.
> >
> 
> I think no matter what, we should still have some sort of
> upper limit on the number of range-sets we accept… after all,
> merge doesn't prevent jumping around ;)
> 
> 
> The problem I have with the upper limit on the number of range sets is the 
> use case someone posted for JPEG2000 streaming.  That has a lot of range sets 
> but is completely legit.  However, the ranges are in ascending order and 
> don't overlap.  Maybe we could count overlaps and/or non-ascending order 
> ranges and fall back to 200 + the whole object if it exceeds a limit.

Right - and the other two use cases in the wild are

-   PDF readers - which fetch something at the start in RQ 1 and then the 
index form the end - and then quick looks images for each page and title pages. 
I've seen them do a second and 3rd request with many 10's of ranges.

-   Some of the streaming video (semi/pro) video editors - which fetch a 
bunch of i-Frames and do clever skip over stuff. Not in the high tens; but 
10-15 ranges common.

-   Likewise for very clever MXF professional editing equipment - the 
largest case (yup - it did crash my server) tried to fetch over 2000 ranges :)

So I think we really should endeavor to allow 50 to a few 100 of them. Or at 
the very least - make it a config option to cut off below 50 or so.

Dw.

Re: Final draft / CVE-2011-3192

[Dirk-WIllem van Gulik]

That is fine - we can do another update tomorrow, say noon zulu - if we expect 
that we do not have a proper patch and/or a 2.0.65 / 2.2.20 in the day 
following.

Weird though - my 2.0.61 and 64 does seem fine. So probably very early 2.0 
series.

Dw

On 24 Aug 2011, at 20:40, Eric Covener wrote:

> I'm seeing Apache 2.0 doesn't accept our RequestHeader syntax due to a
> defect, it misinterprets it as a value and fails startup.
> 
> If we have the opportunity to amend, I think we need to suggest the
> rewrite flavor for Apache 2.0 and earlier, not just 1.3 and earlier.
> 
> Also for 1.3, is our RE safe for non-PCRE? And should we reconsider
> the "5" for something more liberal?
> 
>>   Option 1: (Apache 2.0 and 2.2)
>> 
>>  # drop Range header when more than 5 ranges.
>>  # CVE-2011-3192
>>  SetEnvIf Range (,.*?){5,} bad-range=1
>>  RequestHeader unset Range env=bad-range
>> 
>>  # optional logging.
>>  CustomLog logs/range-CVE-2011-3192.log common env=bad-range
>> 
>>   Option 2: (Also for Apache 1.3)
>> 
>>  # Reject request when more than 5 ranges in the Range: header.
>>  # CVE-2011-3192
>>  #
>>  RewriteEngine on
>>  RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
>>  RewriteRule .* - [F]
> 

Re: DoS with mod_deflate & range requests

[Dirk-Willem van Gulik]

On 24 Aug 2011, at 16:35, Tim Bannister wrote:

> On Tue, Aug 23, 2011, Roy T. Fielding wrote:
>> And the spec says ...
>> 
>>   When a client requests multiple ranges in one request, the
>>   server SHOULD return them in the order that they appeared in the
>>   request.
>> 
>> My suggestion is to reject any request with overlapping ranges or more
>> than five ranges with a 416, and to send 200 for any request with 4-5
>> ranges.  There is simply no need to support random access in HTTP.
> 
> Deshpande & Zeng in http://dx.doi.org/10.1145/500141.500197 describe a
> method for "streaming" JPEG 2000 documents over HTTP, using many more than
> 5 ranges in a single request.
> A client that knows about any server-side limit could make multiple
> requests each with a small number of ranges, but discovering that limit
> will add latency and take more code.

Agreed - I've seen many 10's of ranges in a single request for things like 
clever PDF pagination (or tiny TIFF quicklooks for the pages), clever http fake 
streaming and clever use of jumping to i-Frames.

I think we just need to sit this out - and accept up to RequestFieldSize limit 
bytes on that line - and then do a sort & merge overlaps as needed. 

And then it is fine.

Dw

Final draft / CVE-2011-3192

[Dirk-Willem van Gulik]

Thanks for all the help. All fixes included. Below will go out to announce at 
the top of the hour - unless I see a veto.

Dw.




Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
  Apache HTTPD Security ADVISORY

Date: 20110824 1600Z
Product:  Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions

Description:


A denial of service vulnerability has been found in the way the multiple 
overlapping ranges are handled by the Apache HTTPD server:

 http://seclists.org/fulldisclosure/2011/Aug/175 

An attack tool is circulating in the wild. Active use of this tools has 
been observed.

The attack can be done remotely and with a modest number of requests can 
cause very significant memory and CPU usage on the server. 

The default Apache HTTPD installation is vulnerable.

There is currently no patch/new version of Apache HTTPD which fixes this 
vulnerability. This advisory will be updated when a long term fix 
is available. 

A full fix is expected in the next 48 hours. 

Mitigation:


However there are several immediate options to mitigate this issue until 
that time. 

1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
   either ignore the Range: header or reject the request.

   Option 1: (Apache 2.0 and 2.2)

  # drop Range header when more than 5 ranges.
  # CVE-2011-3192
  SetEnvIf Range (,.*?){5,} bad-range=1
  RequestHeader unset Range env=bad-range

  # optional logging.
  CustomLog logs/range-CVE-2011-3192.log common env=bad-range

   Option 2: (Also for Apache 1.3)

  # Reject request when more than 5 ranges in the Range: header.
  # CVE-2011-3192
  #
  RewriteEngine on
  RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
  RewriteRule .* - [F]

   The number 5 is arbitrary. Several 10's should not be an issue and may be
   required for sites which for example serve PDFs to very high end eReaders
   or use things such complex http based video streaming.

2) Limit the size of the request field to a few hundred bytes. Note that while 
   this keeps the offending Range header short - it may break other headers; 
   such as sizeable cookies or security fields. 

  LimitRequestFieldSize 200

   Note that as the attack evolves in the field you are likely to have
   to further limit this and/or impose other LimitRequestFields limits.

   See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

3) Use mod_headers to completely dis-allow the use of Range headers:

  RequestHeader unset Range 

   Note that this may break certain clients - such as those used for
   e-Readers and progressive/http-streaming video.

4) Deploy a Range header count module as a temporary stopgap measure:

 http://people.apache.org/~dirkx/mod_rangecnt.c

   Precompiled binaries for some platforms are available at:

http://people.apache.org/~dirkx/BINARIES.txt

5) Apply any of the current patches under discussion - such as:

   
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e

Actions:


However there are several immediate options to mitigate this issue until 
that time. 

1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
   either ignore the Range: header or reject the request.

   Option 1: (Apache 2.0 and 2.2)

  # drop Range header when more than 5 ranges.
  # CVE-2011-3192
  SetEnvIf Range (,.*?){5,} bad-range=1
  RequestHeader unset Range env=bad-range

  # optional logging.
  CustomLog logs/range-CVE-2011-3192.log common env=bad-range

   Option 2: (Also for Apache 1.3)

  # Reject request when more than 5 ranges in the Range: header.
  # CVE-2011-3192
  #
  RewriteEngine on
  RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
  RewriteRule .* - [F]

   The number 5 is arbitrary. Several 10's should not be an issue and may be
   required for sites which for example serve PDFs to very high end eReaders
   or use things such complex http based video streaming.

2) Limit the size of the request field to a few hundred bytes. Note that while 
   this keeps the offending Range header short - it may break other headers; 
   such as sizeable cookies or security fields. 

  LimitRequestFieldSize 200

   Note that as the attack evolves in the field you are likely to have
   to further limit this and/or impose other LimitRequestFields limits.

   See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

3) Use mod_headers to completely dis-allow the use of Range headers:

  RequestHeader unset Range 

   Note that this may break certain clients - such as those used for
   e-Readers and progressive/http-streaming video.

4

Re: VOTES please -- CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (Final-6)

[Dirk-Willem van Gulik]

Various suggest on-list and off-list fixes applied. Thanks all.

A few more +1's would be nice :)

Dw.





Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
  Apache HTTPD Security ADVISORY

Date: 20110824 1600Z
Product:  Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions

Description:


A denial of service vulnerability has been found in the way the multiple 
overlapping ranges are handled by the Apache HTTPD server:

 http://seclists.org/fulldisclosure/2011/Aug/175  

An attack tool is circulating in the wild. Active use of this tools has been 
observed.

The attack can be done remotely and with a modest number of requests can cause 
very significant memory and CPU usage on the server. 

The default Apache HTTPD installation is vulnerable.

There is currently no patch/new version of Apache HTTPD which fixes this 
vulnerability. This advisory will be updated when a long term fix is available. 

A full fix is expected in the next 48 hours. 

Mitigation:


However there are several immediate options to mitigate this issue until that 
time. 

1) Use mod_rewrite to limit the number of ranges:

   Option 1:
  # drop Range header when more than 5 ranges.
  # CVE-2011-3192
  SetEnvIf Range (,.*?){5,} bad-range=1
  RequestHeader unset Range env=bad-range

  # optional logging.
  CustomLog logs/range-CVE-2011-3192.log common env=bad-range

   Option 2:
  # Reject request when more than 5 ranges in the Range: header.
  # CVE-2011-3192
  #
  RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
  RewriteRule .* - [F]

   The number 5 is arbitrary. Several 10's should not be an issue and may be
   required for sites which for example serve PDFs to very high end eReaders
   or use things such complex http based video streaming.

2) Limit the size of the request field to a few hundred bytes. Note that while 
this
   keeps the offending Range header short - it may break other headers; such as 
   sizeable cookies or security fields. 

  LimitRequestFieldSize 200

   Note that as the attack evolves in the field you are likely to have
   to further limit this and/or impose other LimitRequestFields limits.

   See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

3) Use mod_headers to completely dis-allow the use of Range headers:

  RequestHeader unset Range 

   Note that this may break certain clients - such as those used for
   e-Readers and progressive/http-streaming video.

4) Deploy a Range header count module as a temporary stopgap measure:

 http://people.apache.org/~dirkx/mod_rangecnt.c

   Precompiled binaries for some platforms are available at:

http://people.apache.org/~dirkx/BINARIES.txt

5) Apply any of the current patches under discussion - such as:

   
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e

Actions:
---
Apache HTTPD users who are concerned about a DoS attack against their server 
should consider implementing any of the above mitigations immediately. 

When using a third party attack tool to verify vulnerability - know that most 
of the versions in the wild currently check for the presence of mod_deflate; 
and will (mis)report that your server is not vulnerable if this module is not 
present. This vulnerability is not dependent on presence or absence of that 
module.

Planning:
-
This advisory will be updated when new information, a patch or a new release is 
available. A patch or new apache release for Apache 2.0 and 2.2 is expected in 
the next 48 hours. Note that, while popular, Apache 1.3 is deprecated.

Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (NEAR FINAL DRAFT-4)

[Dirk-Willem van Gulik]

On 24 Aug 2011, at 15:34, Guenter Knauf wrote:

> can you please apply:
> --- mod_rangecnt.c.orig   Wed Aug 24 16:25:34 2011
> +++ mod_rangecnt.cWed Aug 24 15:26:48 2011

Done.

> which I need on NetWare in order to get ap_hook_post_read_request() proto;
> 
> and maybe we should also add links to mod_rangecnt binaries?
> for Netware:
> http://people.apache.org/~fuankg/httpd/apache_2.2.x-mod_rangecnt.zip
> http://people.apache.org/~fuankg/httpd/apache_2.0.x-mod_rangecnt.zip


Added pointers.

Dw.

VOTES please -- CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (Final-5)

[Dirk-Willem van Gulik]

Folks,

Can I have a few +1's on below - or feedback on what we'd like to have changed ?

*   Would like to get this out in an hour or so ?

*   FIne with the 48 hours commitment of an update ?

Dw.



Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
Date: 20110824 1600Z
Product:  Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions

Description:


A denial of service vulnerability has been found in the way the multiple 
overlapping ranges are handled by the Apache HTTPD server:

 http://seclists.org/fulldisclosure/2011/Aug/175  

An attack tool is circulating in the wild. Active use of this tools has been 
observed.

The attack can be done remotely and with a modest number of requests can cause 
very significant memory and CPU usage on the server. 

The default Apache HTTPD installation is vulnerable.

There is currently no patch/new version of Apache HTTPD which fixes this 
vulnerability. This advisory will be updated when a long term fix is available. 

A full fix is expected in the next 48 hours. 

Mitigation:


However there are several immediate options to mitigate this issue until that 
time:

1) Use mod_rewrite to limit the number of ranges:

   Option 1L
  RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
  RewriteRule .* - [F]

   Option 2:
  SetEnvIf Range (,.*?){5,} bad-range=1
  RequestHeader unset Range env=bad-range
  # optional logging.
  CustomLog logs/range.log "%r %{Range}i %{bad-range}e"

2) Limit the size of the request field to a few hundred bytes. Note that while 
this
   keeps the offending Range header short - it may break other headers; such as 
   sizeable cookies or security fields. 

  LimitRequestFieldSize 200

   Note that as the attack evolves in the field you are likely to have
   to further limit this and/or impose other LimitRequestFields limits.

   See:  
http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

3) Use mod_headers to dis-allow the use of Range headers:

  RequestHeader unset Range 

   Note that this may break certain clients - such as those used for
   e-Readers and progressive/http-streaming video.

4) Deploy a Range header count module as a temporary stopgap measure:

 http://people.apache.org/~dirkx/mod_rangecnt.c

5) Apply any of the current patches under discussion - such as:

   
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e

Actions:
---
Apache HTTPD users who are concerned about a DoS attack against their server 
should consider implementing any of the above mitigations immediately. 

When using a third party attack tool to verify vulnerability - know that most 
of the versions in the wild currently check for the presence of mod_deflate; 
and will (mis)report that your server is not vulnerable if this module is not 
present. This vulnerability is not dependent on presence or absence of that 
module.

Planning:
-
This advisory will be updated when a fix/patch or new release is available. A 
patch or new apache release for Apache 2.0 and 2.2 is expected in the next 48 
hours. Note that, while popular, Apache 1.3 is deprecated.

Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (NEAR FINAL DRAFT-4)

[Dirk-WIllem van Gulik]

On 24 Aug 2011, at 14:07, Dirk-WIllem van Gulik wrote:

*   Folks - do we also need to add Request-Range ?

*   Updated with Rudigers comments., Eric, Florians, Marks.

*   Consensus that the deflate stuff needs to go out reflected.

*   More Comments please. Esp. on the quality and realisticness of the 
mitigtions.

*   Timeline mentioning fine (we've never done that before) -- or best 
avoided ?

My plan is to wait for the US to fully wake up - and then call around 1500Z for 
a few quick +1's to get this out - ideally before 1600 zulu.

Thanks,

Dw.







Title:  CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and 
Apache 2
Date:   20110824 1600Z
# Last Updated:  20110824 1600Z
Product:   Apache Web Server
Versions:  Apache 1.3 all versions, Apache 2 all versions

Description:


A denial of service vulnerability has been found in the way the multiple 
overlapping ranges are handled by the Apache HTTPD server 
(http://seclists.org/fulldisclosure/2011/Aug/175).  

An attack tool is circulating in the wild. Active use of this tools has been 
observed.

The attack can be done remotely and with a modest number of requests leads to 
very significant memory and CPU usage. 

The default Apache HTTPD installation is vulnerable.

There is currently no patch/new version of Apache HTTPD which fixes this 
vulnerability. This advisory will be updated when a long term fix is available. 
A full fix is expected in the next 48 hours. 

Mitigation:


However there are several immediate options to mitigate this issue until that 
time:

1)  Use mod_headers to dis-allow the use of Range headers:

RequestHeader unset Range 

Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.

2)  Use mod_rewrite to limit the number of ranges:

RewriteCond %{HTTP:range} !^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]

3)  Limit the size of the request field to a few hundred bytes. Note that 
while this
keeps the offending Range header short - it may break other headers; 
such as sizable
cookies or security fields. 

LimitRequestFieldSize 200

Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.

See:
http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

4)  Deploy a Range header count module as a temporary stopgap measure:

http://people.apache.org/~dirkx/mod_rangecnt.c

5)  Apply any of the current patches under discussion - such as:


http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e


Actions:
---
Apache HTTPD users who are concerned about a DoS attack against their server 
should consider implementing any of the above mitigations immediately. 

When using a third party attack tool to verify vulnerability - know that most 
of the versions in the wild currently check for the presence of mod_deflate; 
and will (mis)report that your server is not vulnerable if this module is not 
present. This vulnerability is not dependent on presence or absence of that 
module.

Planning:
-

This advisory will be updated when a fix/patch or new release is available. A 
patch or new apache release for Apache 2.0 and 2.2 is expected in the next 48 
hours. Note that, while popular, Apache 1.3 is deprecated. 

Re: Mitigation Range header

[Dirk-WIllem van Gulik]

On 24 Aug 2011, at 14:01, Plüm, Rüdiger, VF-Group wrote:

> Have you tried if the same happens with mod_deflate, but with one of the
> the proposed mitigations in place?

As soon as I reject/block on the range header - all is fine again.

> As said my guess is that this might be an issue with mod_deflate that
> is unrelated to the Range request issue.

Good point.

Dw

Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT-3)

[Dirk-WIllem van Gulik]

*   Folks - do we also need to add Request-Range ?

*   Updated with Rudigers comments., Eric, Florians

*   Consensus that the deflate stuff needs to go out reflected.

*   More Comments please. Esp. on the quality and realisticness of the 
mitigtions.

*   Is this the right list (and order) of the mitigations - or should 
ReWrite be first ?

*   Timeline mentioning fine (we've never done that before) -- or best 
avoided ?

My plan is to wait for the US to fully wake up - and then call for a few quick 
+1's to get this out - ideally before 1600 zulu.

Thanks,

Dw.







Title:  CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and 
Apache 2
Date:   20110824 1600Z
# Last Updated:  20110824 1600Z
Product:   Apache Web Server
Versions:  Apache 1.3 all versions, Apache 2 all versions

Description:


A denial of service vulnerability has been found in the way the multiple 
overlapping ranges are handled by apache 
(http://seclists.org/fulldisclosure/2011/Aug/175).  An attack tool is 
circulating in the wild. Active use of this tools has been observed.

The attack can be done remotely and with a modest number of requests leads to 
very significant memory and CPU usage. 

The default apache installation is vulnerable.

There is currently no patch/new version of apache which fixes this 
vulnerability. This advisory will be updated when a long term fix is available. 
A fix is expected in the next 96 hours. 

Mitigation:


However are several immediate options to mitigate this issue until that time:

1)  Use mod_headers to dis-allow the use of Range headers:

RequestHeader unset Range 

Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.

2)  Use mod_rewrite to limit the number of ranges:

RewriteCond %{HTTP:range} !^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]

3)  Limit the size of the request field to a few hundred bytes. Note that 
while this
keeps the offending Range header short - it may break other headers; 
such as sizable
cookies or security fields. 

LimitRequestFieldSize 200

Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.

See:
http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

3)  Deploy a Range header count module as a temporary stopgap measure:

http://people.apache.org/~dirkx/mod_rangecnt.c

5)  Apply any of the current patches under discussion - such as:


http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e


Actions:
---
Apache HTTPD users are advised to investigate wether they are vulnerable (e.g. 
allow use of the Range header )and consider implementing any of the above 
mitigations immediately. 

When using a third party attack tool to verify vulnerability - know that most 
of the versions in the wild currently check for the presence of mod_deflate; 
and will (mis)report that your server is not vulnerable if this module is not 
present. This vulnerability is not dependent on presence or absence of that 
module.

Planning:
-

This advisory will be updated when a fix/patch or new release is available. A 
patch or new apache release for Apache 2.0 and 2.2 is expected in the next 96 
hours. Note that, while popular, Apache 1.3 is deprecated. 

Re: Mitigation Range header

[Dirk-WIllem van Gulik]

On 24 Aug 2011, at 13:43, Florian Weimer wrote:

> * Dirk-WIllem van Gulik:
> 
>> Hmm - when I remove mod_deflate (i.e. explicitly as it is the default
>> in all our installs) and test on a / entry which is a static file
>> which is large (100k)* - then I cannot get apache on its knees on a
>> freebsd machine - saturating the 1Gbit connection it has (Note: the
>> attack machines *are* getting saturated).  The moment i put in
>> mod_deflate, mod_external filter, etc - it is much easier to get
>> deplete enough resources to notice.
> 
> Oh.  Have you checked memory usage on the server?

I had not - and you are right - quite high. I also tried it on a Ubuntu machine 
- and that one dies right out of the gate - regardless as to wether deflate is 
on- or off.

So I guess this is somewhat OS specific - but indeed - not overly deflate 
specific. Deflate just does something.

Ok - let me rewrite advisory draft !

Dw

Re: Mitigation Range header

[Dirk-WIllem van Gulik]

On 24 Aug 2011, at 13:22, Florian Weimer wrote:

> * Plüm, Rüdiger, VF-Group:
> 
>> As said this has *nothing* to do with mod_deflate. This was IMHO just
>> a guess by the original author of the tool.
> 
> This matches my testing, too.  I see a significant peak in RAM usage on
> a server where "apachectl -M" does not print anything with the string
> "deflate" (so I assume that mod_deflate is not enabled).  This is with
> 2.2.9-10+lenny9 on Debian.
> 
> If it is more difficult to check if mod_deflate is enabled, the advisory
> should tell how to check your server.  If the method I used is the
> correct one, I don't think it's reasonable to suggest disabling
> mod_deflate as a mitigation because it does not seem to make much of a
> difference.

Hmm - when I remove mod_deflate (i.e. explicitly as it is the default in all 
our installs) and test on a / entry which is a static file which is large 
(100k)* - then I cannot get apache on its knees on a freebsd machine - 
saturating the 1Gbit connection it has (Note: the attack machines *are* getting 
saturated).  The moment i put in mod_deflate, mod_external filter, etc - it is 
much easier to get deplete enough resources to notice.

Dw.

*: as I cannot reproduce the issue with very small index.html files.

Re: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT-2)

[Dirk-Willem van Gulik]

*   Updated with Rudigers comments. 

*   Do we have consensus that the deflate stuff needs to go out - is not 
relevant ?

*   More Comments please. Esp. on the quality and realisticness of the 
mitigtions.

Thanks,

Title:  CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and 
Apache 2
Date:   20110824 1600Z
# Last Updated:  20110824 1600Z
Product:   Apache Web Server
Versions:  Apache 1.3 all versions, Apache 2 all versions

Description:


A denial of service vulnerability has been found in the way the multiple 
overlapping ranges are handled by apache 
(http://seclists.org/fulldisclosure/2011/Aug/175). It most commonly manifests 
itself when static content is made available with compression on the fly 
through mod_deflate - but other modules which buffer and/or generate content 
in-memory are likely to be affected as well. 

This is a very common (the default right!?) configuration. 

The attack can be done remotely and with a modest number of requests leads to 
very significant memory and CPU usage. 

Active use of this tools has been observed in the wild.

There is currently no patch/new version of apache which fixes this 
vulnerability. This advisory will be updated when a long term fix is available. 
A fix is expected in the next 96 hours. 

Mitigation:


However are several immediate options to mitigate this issue until that time:

1)  Use mod_headers to dis-allow the use of Range headers:

RequestHeader unset Range 

Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.

2)  Use mod_rewrite to limit the number of ranges:

RewriteCond %{HTTP:range} ^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]

3)  Limit the size of the request field to a few hundred bytes. Note that 
while this
keeps the offending Range header short - it may break other headers; 
such as sizable
cookies or security fields. 

LimitRequestFieldSize 200

Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.

See:
http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

3)  Deploy a Range header count module as a temporary stopgap measure:

http://people.apache.org/~dirkx/mod_rangecnt.c

4)  If your server (only) server static content then disable 
compression-on-the-fly by:

1)  removing mod_deflate as a loaded module and/or by removing any 
AddOutputFilterByType/SetOutputFilter DEFLATE entries.

2)  Disable it with "BrowserMatch .* no-gzip"

See:http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
http://httpd.apache.org/docs/2.2/mod/mod_deflate.html

5)  Apply any of the current patches under discussion - such as:


http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e

Actions:

Apache HTTPD users are advised to investigate wether they are vulnerable (e.g. 
allow Range headers and use mod_deflate) and consider implementing any of the 
above mitigations. 

Planning:


This advisory will be updated when a fix/patch or new release is available. A 
patch or new apache release for Apache 2.0 and 2.2 is expected in the next 96 
hours. Note that, while popular, Apache 1.3 is deprecated. 

Re: Mitigation Range header (Was: DoS with mod_deflate & range requests)

[Dirk-Willem van Gulik]

On 24 Aug 2011, at 12:57, Plüm, Rüdiger, VF-Group wrote:

>> ->   Where possible - disable mod_deflate
>>  
>>  => we sure this covers all cases - or this is a good stopgap ?
> 
> As said this has *nothing* to do with mod_deflate. This was IMHO just
> a guess by the original author of the tool.

Ok - but when I try it on my servers (with the check of the tool removed)  - it 
seems quite impotent unless mod_deflate is in the wire.

And it seems a bit more potent when there is other 'keep in the air' modules 
around.

So I guess mod_deflate is right now the largest 'plug' we have in the server 
which can cause this backup ?

Or is that totally wrong. Happy to stand correctede !


>> ->   Where possible - set LimitRequestFieldSize to a small value
>> 
>>  ->  Suggesting of 128 fine ?
>> 
>> ->   Where this is not possible (e.g. long cookies, auth 
>> headers of serious size) consider using
>>  mod_rewrite to not accept more than a few commas
>> 
>>  =>  anyone a config snipped for this ?
> 
> How about the following (untested) rewrite rule. It should only allow 5
> ranges at max.
> 
> RewriteCond %{HTTP:range} ^bytes=[^,]+(,[^,]+){0,4}$
> RewriteRule .* - [F]


Sounds like a plan ! This mail crossed one I just sent out - lemme update that 
too.

Dw.

CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and Apache 2 (DRAFT)dev

[Dirk-Willem van Gulik]

Comments please. Esp. on the quality and realisticness of the mitigtions.


Title:  CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and 
Apache 2
Date:   20110824 1600Z
# Last Updated:  20110824 1600Z
Product:   Apache Web Server
Versions:  Apache 1.3 all versions, Apache 2 all versions

Description:


A denial of service vulnerability has been found in the way the multiple 
overlapping ranges are handled by apache 
(http://seclists.org/fulldisclosure/2011/Aug/175). It most commonly manifests 
itself when static content is made available with compression on the fly 
through mod_deflate. 

This is a very common (the default right!?) configuration. 

The attack can be done remotely and with a modest number of requests leads to 
very significant memory and CPU usage. 

Active use of this tools has been observed in the wild.

There is currently no patch/new version of apache which fixes this 
vulnerability. This advisory will be updated when a long term fix is available. 
A fix is expected in the next 96 hours. 

Mitigation:


However are several immediate options to mitigate this issue until that time:

1)  Disable compression-on-the-fly by:

1)  removing mod_deflate as a loaded module and/or by removing any 
AddOutputFilterByType/SetOutputFilter DEFLATE entries.

2)  Disable it with "BrowserMatch .* no-gzip"

See:http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
http://httpd.apache.org/docs/2.2/mod/mod_deflate.html

2)  Use mod_headers to dis-allow the use of Range headers:

RequestHeader unset Range 

Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.

2)  Limit the size of the request field to a few hundred bytes. Note that 
while this
keeps the offending Range header short - it may break other headers; 
such as sizable
cookies or security fields. 

LimitRequestFieldSize 200

Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.

See:
http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

3)  Deploy a Range header count module as a temporary stopgap measure:

http://people.apache.org/~dirkx/mod_rangecnt.c

4)  Apply any of the current patches under discussion - such as:


http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e

Actions:

Apache HTTPD users are advised to investigate wether they are vulnerable (e.g. 
allow Range headers and use mod_deflate) and consider implementing any of the 
above mitigations. 

Planning:


This advisory will be updated when a fix/patch or new release is available. A 
patch or new apache release for Apache 2.0 and 2.2 is expected in the next 96 
hours. Note that, while popular, Apache 1.3 is deprecated. 

CVE-2011-3192 (Was: CVE (Was: DoS with mod_deflate & range requests))

[Dirk-Willem van Gulik]

The new Range: header has been given the CVE of

CVE-2011-3192

Please use that in subjects, commits and what not.

Thanks,

Dw.

On 24 Aug 2011, at 09:28, Dirk-Willem van Gulik wrote:

> Folks,
> 
> Have we done (or who is doing a CVE) on this ? So we get immediate 'fixes' 
> out like a tiny patch to count the comma's, a caveated LimitRequestFieldSize 
> 100 or a clever Regex on %{HTTP_Range}.
> 
> Or am I totally asleep and missed the CVE (as my google foo only nets me 
> CVE-2005-2728 right now - which is from 2005!).
> 
> Dw.
> 

Mitigation Range header (Was: DoS with mod_deflate & range requests)

[Dirk-Willem van Gulik]

Folks,

This issue is now active in the wild. So some unified/simple comms is needed. 

What is the wisdom on mitigation advise/briefing until a proper fix it out - in 
order of ease:

->  Where possible - disable mod_deflate

=> we sure this covers all cases - or this is a good stopgap ?

->  Where possible - set LimitRequestFieldSize to a small value

->  Suggesting of 128 fine ?

->  Where this is not possible (e.g. long cookies, auth headers of serious 
size) consider using
mod_rewrite to not accept more than a few commas

=>  anyone a config snipped for this ?

->  Perhaps a stop gap module

http://people.apache.org/~dirkx/mod_rangecnt.c (is this kosher??)

->  Apply patch XXX from the mailing list

Any thoughts ? Followed by a - upgrade as soon as a release is made

Thanks,

Dw

CVE (Was: DoS with mod_deflate & range requests)

[Dirk-Willem van Gulik]

Folks,

Have we done (or who is doing a CVE) on this ? So we get immediate 'fixes' out 
like a tiny patch to count the comma's, a caveated LimitRequestFieldSize 100 or 
a clever Regex on %{HTTP_Range}.

Or am I totally asleep and missed the CVE (as my google foo only nets me 
CVE-2005-2728 right now - which is from 2005!).

Dw.

SSLRenegBufferSize

[Dirk-Willem van Gulik]

Can anyone remember why SSLRenegBufferSize is set at 128k (131072 bytes) 
currently by default ? 

And if that is just an accidental default - or if deep thought has gone into it 
? 

And what are the specific things which are likely to break if it is set 
significantly smaller* ?

Thanks,

Dw.

*: I am still looking at some very rare fringe cases (which back in July I 
expected to having to do with a hole in stacking) - where part of the (SSL) 
stack gets unhappy and somehow overloaded and then may allow security bypassing 
- which I am only seeing a few times a month  -and only when there is a high 
load of users with a long RTT (prolly unrelated).

Bug #30865 -- mod_disk_cache leaves many temporary files slowing file system

[Dirk-Willem van Gulik]

Reudiger,

Why is:

https://issues.apache.org/bugzilla/show_bug.cgi?id=30865

still open ? You are not sure it was fixed ? Or we just forgot about it ?

Thanks,

Dw.

Re: FOSDEM

[Dirk-WIllem van Gulik]

On 1 Feb 2011, at 22:17, Jorge Schrauwen wrote:

> Any httpd people coming to FOSDEM in Brussels, Belgium this weekend?

+1 for me.

Dw

Re: Any standard on picking a response status out of several possible?

[Dirk-Willem van Gulik]

On 10 Nov 2010, at 14:42, Dan Poirier wrote:

> If multiple response statuses would be valid for a request (e.g. 403,
> 413), is there any standard on how to pick one?  I looked through RFC
> 2616 but didn't see anything.  Or is it just an implementation detail?

This was subject of a fair bit of debate at the time; and from what I recall it 
was tried to reduce this to a non issue (i.e. letting the implementor make the 
call) by fairly carefully having the 2x/3x and 4x meaning right (success, retry 
with extra info and no-go) - along with making sure that the higher numbers are 
increasingly more narrow in their scope - with the assumption that implementors 
would only use those if the semantics where truly applicable and 'actionable' 
by a client.

Guess that does not answer the question - but in your example 403 (forbidden) 
vs 413 (too large) - one probably wants to ask the question - is there anything 
the client can do (perhaps change some POST/form parameter to reduce the 
requested size) - or is it purely forbidden because if its size. If it is the 
first I'd do a 413 (so smarter clients can reduce what they get) and 
distinguish it form a 403 lost case - while if it is the latter - a 403 will be 
more meaningful to a wider range of clients.

Hope that helps,

Dw

Re: Log file rotation patch

[Dirk-Willem van Gulik]

On 4 Nov 2010, at 21:26, Brian J. France wrote:

> With the current patch, see link below, it changes the syntax to ErrorLog to 
> this:
> 
>  ErrorLog file-path|syslog[:facility] [rotating[:]]

Nice!

> There is one security issue that people may have a problem with in that the 
> directory path for the log file has to be writeable by the User that apache 
> drops privilege to.  This is because all the children will need to re-open 
> the log file and the first one will create it.

That is a pretty big eek. Wondering if we need a logging child - but then one 
would end up with the rotatelog utility again :)

Dw.

smime.p7s
Description: S/MIME cryptographic signature