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
