<div dir="ltr"><div dir="ltr"><br></div><div>Hello, Amos,</div><div><br></div><div dir="ltr">Thank you so much for such a detailed answer.<br><br>> >  > >  http_access allow is_bank user1 all<br>> >  > ><br>> >  > >  ssl_bump splice    is_bank user1 all<br>> ><br>> > I thought that re-authentication only occurs during a deny action within<br>> > http_access directives when the final ACL is authentication-based. If<br>> > so, the "all ACL" hack should only be applied to those specific rules,<br>> > correct?<br>> <br>> The authentication is still re-checked by Squid on every ACL test.<br>> There are a login cache, and helper result cache preventing the client<br>> agent and user being bothered by this frequent re-test.<br>> <br>> However, if either of those cached entries expire, then the auth system<br>> gets involved again immediately regardless of previous check results.</div><div dir="ltr"><br>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. </div><div dir="ltr">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.</div><div dir="ltr"><br></div><div>In the case of "http_access deny auth-acl" rules, adding "all" will change the 407 response to a 403.</div><div><br></div><div>Kind regards,</div><div>     Ankor.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">вт, 24 мар. 2026 г. в 16:29, Amos Jeffries <<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 23/03/2026 16:17, Andrey K wrote:<br>
> Hello, Alex and Amos,<br>
> <br>
> Thank you so much for such a detailed response and policy analysis.<br>
> <br>
> @Amos:<br>
>  > * use "all ACL" hack to prevent re-authentication of users:<br>
> <br>
>  > >  http_access allow is_bank user1 all<br>
>  > ><br>
>  > >  ssl_bump splice    is_bank user1 all<br>
> <br>
> I thought that re-authentication only occurs during a deny action within <br>
> http_access directives when the final ACL is authentication-based. If <br>
> so, the "all ACL" hack should only be applied to those specific rules, <br>
> correct?<br>
<br>
The authentication is still re-checked by Squid on every ACL test.<br>
There are a login cache, and helper result cache preventing the client <br>
agent and user being bothered by this frequent re-test.<br>
<br>
However, if either of those cached entries expire, then the auth system <br>
gets involved again immediately regardless of previous check results.<br>
<br>
<br>
> <br>
> After some testing with the "all ACL" hack, I noticed that it limits the <br>
> flexibility of the deny_info mechanism. It seems deny_info is always <br>
> triggered for the 'all' ACL in this case. Don't you think it would be <br>
> useful to mention this in the wiki article (<a href="https://wiki.squid-" rel="noreferrer" target="_blank">https://wiki.squid-</a> <br>
> <a href="http://cache.org/Features/Authentication" rel="noreferrer" target="_blank">cache.org/Features/Authentication</a> <<a href="https://wiki.squid-cache.org/" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/</a> <br>
> Features/Authentication>)?<br>
> <br>
<br>
Nod. deny_info rules are tied to the last ACL on the line.<br>
<br>
If you need to use that directive together with the "all hack", then <br>
instead of using the "all" ACL directly you can define some custom ones <br>
that have the same behaviour to tie to deny_info instead.<br>
For example;<br>
<br>
  acl bounce src all<br>
  deny_info ... bounce<br>
<br>
  acl reject src all<br>
  deny_info ... reject<br>
<br>
  http_access deny ... bounce<br>
  http_access deny ... reject<br>
<br>
<br>
> In my testing, I found that the following rules:<br>
>    http_access deny !login<br>
>    http_access deny login !all<br>
> behave equally. Are there any subtle differences in how they work?<br>
> <br>
<br>
No Credentials:<br>
  - both will trigger auth (needed to test "login").<br>
<br>
Good Credentails:<br>
  - both will skip (line as a whole is a non-match)<br>
<br>
Bad credentials:<br>
  - First will match, "login" being last triggers a re-auth.<br>
  - Second will skip ("!all" made the line a non-match, and suppressed <br>
re-auth trigger).<br>
<br>
<br>
This same subtle loophole in security can often occur when the first <br>
auth related things done are only a test to detect specific usernames <br>
and/or group membership. They trigger the authentication process, but <br>
maybe not always/reliably. That is why I recommend always having one of <br>
these clear "http_access deny !login" lines.<br>
<br>
<br>
> Just out of curiosity, is it possible to make the proxy return 403 <br>
> Forbidden (instead of the default 407 Proxy Authentication Required) for <br>
> client requests that lack authentication information (i.e., no Proxy- <br>
> Authorization header), while returning 200 OK for requests with valid <br>
> credentials?<br>
<br>
Yes. Place this before anything that requires login:<br>
<br>
   acl nologin req_header Proxy-Authorization .<br>
   http_access deny nologin<br>
<br>
Though, be careful with that. The 407 is how client software knows to <br>
send credentials in the first place.<br>
<br>
<br>
HTH<br>
Amos<br>
</blockquote></div></div>