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@xxxxxxxxxxxxx] Sent: Tuesday, July 26, 2011 3:41 PM To: squid-users@xxxxxxxxxxxxxxx Subject: RE: 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
