[squid-users] Policy with multiple ACL calls

[Amos Jeffries]

On 23/03/2026 16:17, Andrey K wrote:
> Hello, Alex and Amos,
> 
> Thank you so much for such a detailed response and policy analysis.
> 
> @Amos:
>  > * use "all ACL" hack to prevent re-authentication of users:
> 
>  > >  http_access allow is_bank user1 all
>  > >
>  > >  ssl_bump splice    is_bank user1 all
> 
> I thought that re-authentication only occurs during a deny action within 
> http_access directives when the final ACL is authentication-based. If 
> so, the "all ACL" hack should only be applied to those specific rules, 
> correct?

The authentication is still re-checked by Squid on every ACL test.
There are a login cache, and helper result cache preventing the client 
agent and user being bothered by this frequent re-test.

However, if either of those cached entries expire, then the auth system 
gets involved again immediately regardless of previous check results.


> 
> After some testing with the "all ACL" hack, I noticed that it limits the 
> flexibility of the deny_info mechanism. It seems deny_info is always 
> triggered for the 'all' ACL in this case. Don't you think it would be 
> useful to mention this in the wiki article (https://wiki.squid- 
> cache.org/Features/Authentication <https://wiki.squid-cache.org/ 
> Features/Authentication>)?
> 

Nod. deny_info rules are tied to the last ACL on the line.

If you need to use that directive together with the "all hack", then 
instead of using the "all" ACL directly you can define some custom ones 
that have the same behaviour to tie to deny_info instead.
For example;

  acl bounce src all
  deny_info ... bounce

  acl reject src all
  deny_info ... reject

  http_access deny ... bounce
  http_access deny ... reject


> In my testing, I found that the following rules:
>    http_access deny !login
>    http_access deny login !all
> behave equally. Are there any subtle differences in how they work?
> 

No Credentials:
  - both will trigger auth (needed to test "login").

Good Credentails:
  - both will skip (line as a whole is a non-match)

Bad credentials:
  - First will match, "login" being last triggers a re-auth.
  - Second will skip ("!all" made the line a non-match, and suppressed 
re-auth trigger).


This same subtle loophole in security can often occur when the first 
auth related things done are only a test to detect specific usernames 
and/or group membership. They trigger the authentication process, but 
maybe not always/reliably. That is why I recommend always having one of 
these clear "http_access deny !login" lines.


> Just out of curiosity, is it possible to make the proxy return 403 
> Forbidden (instead of the default 407 Proxy Authentication Required) for 
> client requests that lack authentication information (i.e., no Proxy- 
> Authorization header), while returning 200 OK for requests with valid 
> credentials?

Yes. Place this before anything that requires login:

   acl nologin req_header Proxy-Authorization .
   http_access deny nologin

Though, be careful with that. The 407 is how client software knows to 
send credentials in the first place.


HTH
Amos