[squid-users] squid asking for authentication repeatedly

[Amos Jeffries]

On 13/12/17 04:10, Paul Hackmann wrote:
> Amos,
> 
> The squid version is 3.1.19.

Please upgrade. There have been a *lot* of authentication related issues 
that got solved in the years since that version was released. IIRC 
several involved nasty things like the looping you described.

All current OS distributions have more recent Squid versions available. 
Or worst-case custom building is not very hard.


>  The network is set up with a 192.168.0.X 
> network on the lan side, and a 192.168.1.x network on the internet 
> side.  Both ports 3120 and 4120 require authentication,


NOTE: port 4120 is an intercepted port. HTTP Proxy Authentication on 
traffic arriving there is prohibited, since the HTTP traffic syntax is 
origin-form.

However that said, your config displayed below contradicts what you 
wrote above. Port 41290 traffic does *not* use authentication - the only 
restriction on port 4120 traffic is that it be going to one of the 
whitelisted domains. Period. There is absolutely no restriction on what 
happens or can be done when going to those domains.



> but port 4120 is 
> meant to be restricted to only the whitelisted sites which are in a 
> separate file.  Port 3120 allows access to any site.  The browser 
> causing trouble is configured for port 3120, not 4120.  Here is my 
> squid.conf file:
> 
...
> 
> #not sure what this line does
> acl manager url_regex -i ^cache_object:// +i 
> ^https?://[^/]+/squid-internal-mgr/
> 

The above line defines an ACL which matches requests for Squids internal 
cache management reports. For both the Squid-2+ and Squid-3.4+ 
management APIs.

Your Squid version requires this to be configured. Current releases 
provide it as a built-in default ACL so you don't need to track or fix 
its definition changes during upgrade.

...
> http_access allow CONNECT localnet

Bad. All LAN clients are allowed to open arbitrary TCP connections 
(CONNECT tunnels) through the proxy *to anywhere* absolutely zero 
restrictions.

The entire point of the "deny CONNECT !SSL_ports" and other default 
security rules is to prohibit attackers and infected LAN clients from 
using the proxy to spread nasty traffic around.

To be useful those default security measure must be placed *first* in 
the http_access ordering and written exactly as provided in the default 
installation. Your own rules should be applied to the traffic which gets 
past those basic precautions.


> http_access deny deny_websites
> http_access allow allowed_clients ncsa_users
> http_access deny !allowed_clients
> #http_access allow ncsa_users
> http_access allow manager localhost
> http_access deny manager
> http_access deny !Safe_ports
> #http_access deny CONNECT !SSL_ports
> http_access allow localhost
> #http_access allow localnet
> 
> http_access deny all
> 
> If the conf file is a mess, or has some problems, feel free to say so, 
> as I don't know what all of the directives in it are for.  I marked a 
> couple of lines I don't understand.  I would be happy for it to be 
> optimized more if anyone has ideas.
> 

I recommend you write your http_access something like so:


  http_access deny !Safe_ports
  http_access deny CONNECT !SSL_ports
  http_access allow manager localhost
  http_access deny manager

  # domains in deny_websites are DENIED for everybody.
  http_access deny deny_websites

  # domains in whitelist are ALLOWED for everybody
  http_access allow whitelist

  # port 4120 traffic is restricted to the above whitelisted domains
  http_access deny portX

  # otherwise; for port 3120 traffic ...

  # only specific clients with whitelisted IPs can use the proxy ...
  http_access deny !allowed_clients

  # ... and must also login
  http_access deny !ncsa_users

  http_access allow localnet

  http_access deny all


If the above still has the looping issue then I think the problem is 
related to how the Browser is using its TCP connections.

Some Browsers used to open many parallel TCP connections and start 
requesting stuff immediately. But their internal credential handling 
seemed not to cope with the parallelism, treating the 2nd through Nth 
auth challenges as a sign that the 1st connections credentials were invalid.

This was particularly bad for any Browsers configured to auto-load many 
tabs on startup. I've not heard of it happening in quite a while though, 
so it may be fixed in current Browsers. Or maybe they just handle tabs 
differently that does not trigger so easily.

Amos