RE: [squid-users] Authentication infinite loop

I just verified that 3.2.0.10 exhibits this digest authentication problem, and I've updated the bug report you (Amos) referenced accordingly.

I also verified that 3.1.14 does *NOT* have this problem (and noted it in the same bug report).

Thanks for the response, that's good enough for me for now.

Dave

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: Tuesday, July 26, 2011 3:41 PM
To: squid-users_at_squid-cache.org
Subject: RE: [squid-users] Authentication infinite loop

 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

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1390 / Virus Database: 1518/3789 - Release Date: 07/26/11
Received on Wed Aug 10 2011 - 21:27:13 MDT