Alex Rousskov wrote:
Hello,
Squid detects forwarding loops in most configurations, but breaks
them (using a customizable HTTP_FORBIDDEN response) only when working as
an accelerator. Squid does not break loops when working as a transparent
proxy. Interestingly enough, the breaking code comment (in the patch
below) says that both cases are covered. Perhaps the exclusion of
transparent mode was not done on purpose.
I understand that forwarding loops in transparent environment are
usually caused by misconfiguration. However, when an admin is unable to
fix the problem promptly, should not we help her by breaking the loop?
Please note that a persistent loop is going to be broken anyway, when
the Via and X-Forwarded-For headers exceed header size limit, but that
wastes a lot of resources and may also crash Squid.
Should we break forwarding loops in transparent mode?
Yes.
Keep in mind the fact that any crash during header processing opens the
doorway for DDoS sooner rather than later. I would go so far as to
suggest making it abort cleanly on mode. Not just these two.
Might be time for a configuration error page to accompany this change as
well. Not just access denied. The wiki search queries are growing for
people looking for "access denied" message then some peer or
interception config option.
Amos
Thank you,
Alex.
=== modified file 'src/client_side_reply.cc'
--- src/client_side_reply.cc 2009-04-10 09:23:50 +0000
+++ src/client_side_reply.cc 2009-06-24 20:33:37 +0000
@@ -640,7 +640,8 @@
/*
* Deny loops when running in accelerator/transproxy mode.
*/
- if (http->flags.accel && r->flags.loopdetect) {
+ if (r->flags.loopdetect &&
+ (http->flags.accel || http->flags.transparent)) {
http->al.http.code = HTTP_FORBIDDEN;
err =
clientBuildError(ERR_ACCESS_DENIED, HTTP_FORBIDDEN, NULL,
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
Current Beta Squid 3.1.0.9
