httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <>
Subject Re: breach attack
Date Tue, 20 Aug 2013 08:17:55 GMT

Op 10 aug. 2013, om 21:35 heeft Reindl Harald <> het volgende
> 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

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.

View raw message