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
_______________________________________________
squid-users mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-users
