RE: [squid-users] Authentication infinite loop

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 27 Jul 2011 10:40:33 +1200

 On Tue, 26 Jul 2011 15:05:22 -0700, David Parks wrote:
> After some more testing I'm finding more cause for concern here. I'm
> using
> 3.2.0.9 in this test.

 Please use 3.2.0.10. .9 has some big issues.

>
> Digest authentication is configured. I am now just using a simple
> auth
> helper script which sits in a loop and outputs "ERR" (as per the
> docs, this
> output indicates "user not found", though in another test I found
> that
> outputting an incorrect password hash has the same effect).
> Nothing interesting shows up in cache.log during any of this.
>
> Here is the behavior I see:
>
> - Run squid
> - Open the browser w/ squid instance configured as proxy
> - Browser indicates that it's trying to make a connection to the
> default
> home page (google in this case), waiting
> - Squid auth helper receives nothing (I've got it copying output to a
> debug
> file for viewing)
>
> - Timeout in around 75 seconds
>
> - Logs show user "-" received TCP_DENIED status (I believe this means
> a 407
> went back to the browser, but I wasn't monitoring for this
> specifically)

 Don't assume. Unless the log shows 407 as the status (ie
 TCP_DENIED/407) there are other things from explicit ACLs, too-big
 headers and bodies, mangled credentials, or unparsable header values
 which can cause DENIED.

> - Still auth helper log shows that it received nothing
> - Browser requests user/pass popup
>
> - Entering user/pass sends the entry to the auth helper which replies
> with
> "ERR"
> - Browser pops up the authentication dialogue again
> - Entering the same user/pass again causes the logs to spam user
> "username"
> with status TCP_DENIED as quickly as possible (notice that the log
> now shows
> the username, not "-")
>
>
> Example auth helper script used:
> #!/bin/bash
> while read LINE; do
> echo "$LINE" >>/tmp/output
> echo "ERR"
> done
>

 Sounds like http://bugs.squid-cache.org/show_bug.cgi?id=3186

 There is a workaround posted, but it is not a nice one.

 We need to ensure that unchecked is ONLY set if the browser actually
 sent whole new details. If the TTL has expired a background check needs
 to be kicked without altering the existing ok/err state of the
 credentials. There is a "grace" period where the old value may be used
 while an background revalidate with the helper is done.

 Amos

>
> -----Original Message-----
> From: David Parks
>
> In doing some dev work I see a situation where squid gets into an
> infinite
> loop with the browser. The situation:
>
> 1) Browser attempts digest authentication against squid (running with
> a
> custom auth helper)
> 2) auth helper fails user authentication
> 3) I believe squid caches the authentication failure
> 4) Browser requests a page using the above authentication
> 5) Squid replies with 407 - authentication required
> 6) INFINITE LOOP: (Browser retries request : squid replies with 407)
>
> The above loop running locally can rack up a meg of data transfer in
> just
> seconds.
>
> I remember dealing with this issue some time back in some other work
> and
> just don't recall what I did about it.
>
> I'm running a custom auth helper, log daemon, and url rewrite helper.
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1390 / Virus Database: 1518/3788 - Release Date:
> 07/25/11
Received on Tue Jul 26 2011 - 22:40:37 MDT

This archive was generated by hypermail 2.2.0 : Wed Jul 27 2011 - 12:00:03 MDT