On 20/09/2012 11:34 p.m., Stephane CHAZELAS wrote:
2012-09-19 17:07:46 +0300, Eliezer Croitoru:
On 9/19/2012 4:36 PM, Stephane CHAZELAS wrote:
But only when providing with a User-Agent oddly enough (and also
when inserting a 10 second delay between the two requests).
Then, I tried to do the same query from a different client and
since then, I cannot reproduce it anymore (even if I do a
different request), and I see no merging in conntrackd. So I
don't have the full picture here, and reckon it's going to be
difficult to investigate as I don't know how to reproduce it
consistently.
I've got network captures, but only on the down side (between
the client and the proxy).
I think it's better to be moved into squid-users since it's not
really about squid code.
so next time reply to squid-users@squid-cache.org
OK. Note that squid has been working perfectly with tproxy for
several months, and the issue is only coming up now because of
that new buggy HTTP client we're evaluating that behaves in an
unexpected way (makes a request, doesn't read the response and
makes another identical request). I was raising it to -dev
because it looks potentially like a serious denial of service
vulnerability in squid.
It is a vulnerability in theory, but not one we can do anything about in
practice. It is perfectly legitimate HTTP to receive millions of
requests per second from a single client (for example another proxy
serving as gateway fro a whole country). We also make no practice of
retaining previous requests around to compare details, it is far more
efficient to reject two requests as they arrive than to compare N
requests against each other in case one is a repeat.
The DoS vulnerability aspect comes down to how well/efficiently you
configure the proxy access controls. When well done the proxy should
have a very high rejection speed for most potential.attack requests.
Most but not all. DoS resolution is all about raising the bar as high as
possible.
Amos
