[squid-users] Policy with multiple ACL calls

[Andrey K]

Hello, Amos,

Thank you so much for such a detailed answer.

> >  > >  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.

I am sorry, but I still don’t quite understand why we should use "all-hack"
at the end of "http_access allow auth-acl" rules.
I suppose if the login cache expires, Squid — if it has credentials in the
current transaction — will pull the helper again. Otherwise, it should send
a 407 back to the user regardless of whether the "all" ACL is present at
the end of the rule or not.

In the case of "http_access deny auth-acl" rules, adding "all" will change
the 407 response to a 403.

Kind regards,
     Ankor.

вт, 24 мар. 2026 г. в 16:29, Amos Jeffries <squid3 at treenet.co.nz>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20260325/1c6a3fb6/attachment.htm>