[squid-users] Policy with multiple ACL calls

[Andrey K]

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?

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)?

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?

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?

Kind regards,
    Ankor.


пт, 20 мар. 2026 г. в 01:30, Amos Jeffries <squid3 at treenet.co.nz>:

> On 20/03/2026 02:20, Andrey K wrote:
> > Hello,
> >
> > I'd be curious to know, is the dstdomain ACL evaluated once per
> > transaction or every time it occurs in the policy?
> >
> > For example, in the following simplified policy, will the Squid go
> > through the long list of bank-sites once or six times?
> >
> >    acl bank-sites dstdomain bank-sites.txt
> >    acl user1 proxy_auth user1
> >    acl user2 proxy_auth user2
> >    acl user3 proxy_auth user3
> >
> >    http_access allow user1 bank-sites
> >    http_access allow user2 bank-sites
> >    http_access deny  user3 bank-sites
> >
> >    ssl_bump splice    user1 bank-sites
> >    ssl_bump bump      user2 bank-sites
> >    ssl_bump terminate user3 bank-sites
> >
> > I believe that the ACL is calculated only once and the result is reused.
>
> No. The access control lines are tested top-down, left-to-right. Each
> ACL is tested when it is encountered.
>
> Some types (eg. that do helper lookup) have an internal cache of results
> they can use to avoid repeated expensive tests. But all the "fast" type
> ACLs like dstdomain are checked in full each time they are tested, since
> a cache lookup is slower than re-doing the test.
>
>
> >
> > How do you think, would it be more efficient to use annotations, like in
> > the following example?
> >
> >    acl bank-sites dstdomain bank-sites.txt
> >    acl user1 proxy_auth user1
> >    acl user2 proxy_auth user2
> >    acl user3 proxy_auth user3
> >
> >    acl annotate_banks annotate_client categories+=bank
> >    acl is_bank note categories bank
> >
> >    # evaluate bank-sites just once and annotate a connection
> >    http_access deny bank-sites annotate_banks !all
> >
> >    http_access allow user1 is_bank
> >    http_access allow user2 is_bank
> >    http_access deny  user3 is_bank
> >
> >    ssl_bump splice    user1 is_bank
> >    ssl_bump bump      user2 is_bank
> >    ssl_bump terminate user3 is_bank
> >
>
> * dstdomain is a string comparison between HTTP URL domain name, and the
> configured ACL value.
>
> * is_bank is a string comparison between the transaction annotation and
> the configured ACL value.
>
>   - dstdomain MAY require a DNS lookup if the URL contains a raw-IP
> address. There is a DNS cache speeding up most of the lookups, but they
> still happen. You can use "-n" flag on the ACL to just compare the
> raw-IP as string against the "dstdomain" list.
>
>   - is_bank requires the categories search and annotation marking to
> occur before it will match. That occurs every time "bank-sites" ACL is
> checked.
>
>
> For efficiency, the best practice is:
>
> A) place first the ACLs that will prune down future work fastest. That
> goes for both the top-down and the left-to-right orders separately.
>
> B) prefer doing "fast" group ACL tests before "slow" group ACL tests.
>    Unless this will break (A) and increase the total work by Squid.
>
> C) make use of your knowledge of group/set elimination to reduce
> repeatedly using ACL tests. Not having to test at all is faster than
> even the "fast" ACL type checks.
>
>
> Applying the above practices I would, ...
>
> * ensure that there is a clean login in http_access before any of the
> userN Acl tests:
>
>   > auth_param ...
>   > acl login proxy_auth REQUIRED
>   >
>   > ... allow things that do not require login
>   > http_access deny !login
>   > ... other things that do require login
>
>
> * do the "is_bank" test before authentication username checks:
>
>  >  http_access allow is_bank user1
>  >  http_access allow is_bank user2
>  >  http_access deny  is_bank user3
>  >
>  >  ssl_bump splice    is_bank user1
>  >  ssl_bump bump      is_bank user2
>  >  ssl_bump terminate is_bank user3
>
>
> * use "all ACL" hack to prevent re-authentication of users:
>
>  >  http_access allow is_bank user1 all
>  >  http_access allow is_bank user2 all
>  >  http_access deny  is_bank user3 all
>  >
>  >  ssl_bump splice    is_bank user1 all
>  >  ssl_bump bump      is_bank user2 all
>  >  ssl_bump terminate is_bank user3 all
>
>
> * combine user1 and user2 to reduce http_access total checks
>
>  >  acl bank-users any-of user1 user2
>  >  http_access allow is_bank bank-users all
>  >  http_access deny  is_bank user3 all
>  >
>  >  ssl_bump splice    is_bank user1 all
>  >  ssl_bump bump      is_bank user2 all
>  >  ssl_bump terminate is_bank user3 all
>
>
> Also, I would highly recommend adding an ssl_bump rule to explicitly
> indicate what is to happen to HTTP traffic that is not going to those
> three userN. For example:
>
>  >  ssl_bump splice all
>
>
> Cheers
> Amos
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20260323/ca3bc7a5/attachment.htm>