[squid-users] Policy with multiple ACL calls

[Amos Jeffries]

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