Re: [squid-users] Pass MYPORT to proxy_auth?

On 14/09/11 21:36, David Rodman wrote:
> HI Amos -
>
> I appreciate the thought -- but here's the rub:
>> Use the "fake" Basic authenticator to get around the small problem
>> of needing an auth module configured.
>
> That is the only way to acquire a username and password from the
> user, right? So here's the problem:
>
> If the user enters an invalid username and password, the fake
> authenticator will still say "OK". That result is cached as valid,
> and then when the external acl proc does the actual authentication
> and says "ERR", squid will not re-execute the fake authenticator
> because it thinks it already has a valid set of credentials from that
> one.

I forgot to ask which Squid you are using.

The external ACL using %LOGIN have been made proper side-band
authentication and should trigger re-challenge under the same conditions
as proxy_auth ACL (ie if it it last on the line).

That will not force the browser to do anything though, it may still
re-send the same credentials to the same port. Or it my try repeatedy,
then ask the user (popup) who enters the same ones.

>
> That's why I look up the username/password combination in my
> proxy_auth external, so that it will not say "OK" unless there's at
> least a good chance that we're going to authenticate this user.
> (incidentally - I am using the port to differentiate user groups;
> each group has its own authentication database and its own set of
> permissions used by the rewriter program.)

The definitely the two-helper setup in Squid is best for all current
releases. Group permissions are too "fuzzy" (I think thats the word
anyway) in relation to users for the strict yes/no results which Squid
helper have to produce for validity. Things get weird real quick when
usernames can be both valid and invalid simultaneously with the same
password.

>
> It's working OK this way but ugly because of the multiple database
> lookups and multiple external programs. If I could just pass the
> port number to the basic authentication helper, that would do the
> trick. The information must be known to Squid at the time it calls
> the auth program, because there has to be a live HTTP request
> structure, and that's where the port number is stored. But that
> structure is not visible to the authenticate routine that actually
> invokes the external program.
>

The details are known yes. But what happens when a second request for
the same username comes in the wrong port within TTL of a request from
the acceptible port? all active requests for the user will become
invalid for ten minutes, with only a new password being able to break
out of that. Trivial DoS vulnerability which users can self-trigger.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.15
   Beta testers wanted for 3.2.0.11