Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: unknown (athena.apache.org: error in processing during lookup of
 dirkx@webweaving.org)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: breach attack
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
In-Reply-To: <52069600.6060400@thelounge.net>
Date: Tue, 20 Aug 2013 10:17:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AB7DF906-7E3E-439F-A35E-BD8129D7238F@webweaving.org>
References: 
 <CAMDeyhwCYYQMK+WTfvge7y20AqEB1=kqMHgqKYhr3kBWkZyYzA@mail.gmail.com>
 <CAMDeyhww0PMoH95YxuJe+7r=Gi1z2T+UPh+8CQg4KTLBXqLQqg@mail.gmail.com>
 <20130809210422.GA14384@redhat.com> <2250572.368Yd9bN48@k>
 <52069600.6060400@thelounge.net>
To: dev@httpd.apache.org


Op 10 aug. 2013, om 21:35 heeft Reindl Harald <h.reindl@thelounge.net> =
het volgende geschreven:
>=20
> IMHO that is all the wrong train
>=20
> "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
>=20
> 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.=