Re: Policy with multiple ACL calls
Andrey K <[email protected]> Wed, 25 Mar 2026 16:29:02 +0300
| Newsgroups | gmane.comp.web.squid.general |
|---|---|
| Message-ID | <CADJd0Y0J2mjhvoVkY0HZx9t54OU47H_sSxhs5Za4prTkWTMc-g@mail.gmail.com> |
--===============8151014956301393872==
Content-Type: multipart/alternative; boundary="0000000000000822d8064dd94160"
--0000000000000822d8064dd94160
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 withi=
n
> > 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=E2=80=99t quite understand why we should use "a=
ll-hack"
at the end of "http_access allow auth-acl" rules.
I suppose if the login cache expires, Squid =E2=80=94 if it has credentials=
in the
current transaction =E2=80=94 will pull the helper again. Otherwise, it sho=
uld 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.
=D0=B2=D1=82, 24 =D0=BC=D0=B0=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 16:29, Amo=
s Jeffries <[email protected]>:
> 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 withi=
n
> > 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 th=
e
> > 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) fo=
r
> > 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
>
--0000000000000822d8064dd94160
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div>Hello, Amos,</div><div><br=
></div><div dir=3D"ltr">Thank you so much for such a detailed answer.<br><b=
r>> >=C2=A0 > > =C2=A0http_access allow is_bank user1 all<br>&g=
t; >=C2=A0 > ><br>> >=C2=A0 > > =C2=A0ssl_bump splice =
=C2=A0 =C2=A0is_bank user1 all<br>> ><br>> > I thought that re-=
authentication only occurs during a deny action within<br>> > http_ac=
cess 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>>=C2=A0<br>> The authentication is st=
ill 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>>=C2=A0<br>> However, if eithe=
r of those cached entries expire, then the auth system<br>> gets involve=
d again immediately regardless of previous check results.</div><div dir=3D"=
ltr"><br>I am sorry, but I still don=E2=80=99t quite understand why we shou=
ld use "all-hack" at the end of "http_access allow auth-acl&=
quot; rules.=C2=A0</div><div dir=3D"ltr">I suppose if the login cache expir=
es, Squid =E2=80=94 if it has credentials in the current transaction =E2=80=
=94 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 o=
f the rule or not.</div><div dir=3D"ltr"><br></div><div>In the case of &quo=
t;http_access deny auth-acl" rules, adding "all" will change=
the 407 response to a 403.</div><div><br></div><div>Kind regards,</div><di=
v>=C2=A0 =C2=A0 =C2=A0Ankor.</div><br><div class=3D"gmail_quote gmail_quote=
_container"><div dir=3D"ltr" class=3D"gmail_attr">=D0=B2=D1=82, 24 =D0=BC=
=D0=B0=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 16:29, Amos Jeffries <<a href=
=3D"mailto:[email protected]">[email protected]</a>>:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t: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>
>=C2=A0 > * use "all ACL" hack to prevent re-authentication=
of users:<br>
> <br>
>=C2=A0 > > =C2=A0http_access allow is_bank user1 all<br>
>=C2=A0 > ><br>
>=C2=A0 > > =C2=A0ssl_bump splice =C2=A0 =C2=A0is_bank user1 all<b=
r>
> <br>
> I thought that re-authentication only occurs during a deny action with=
in <br>
> http_access directives when the final ACL is authentication-based. If =
<br>
> so, the "all ACL" hack should only be applied to those speci=
fic 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 i=
t 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=3D"https://wiki.sq=
uid-" rel=3D"noreferrer" target=3D"_blank">https://wiki.squid-</a> <br>
> <a href=3D"http://cache.org/Features/Authentication" rel=3D"noreferrer=
" target=3D"_blank">cache.org/Features/Authentication</a> <<a href=3D"ht=
tps://wiki.squid-cache.org/" rel=3D"noreferrer" target=3D"_blank">https://w=
iki.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", t=
hen <br>
instead of using the "all" ACL directly you can define some custo=
m ones <br>
that have the same behaviour to tie to deny_info instead.<br>
For example;<br>
<br>
=C2=A0 acl bounce src all<br>
=C2=A0 deny_info ... bounce<br>
<br>
=C2=A0 acl reject src all<br>
=C2=A0 deny_info ... reject<br>
<br>
=C2=A0 http_access deny ... bounce<br>
=C2=A0 http_access deny ... reject<br>
<br>
<br>
> In my testing, I found that the following rules:<br>
>=C2=A0 =C2=A0 http_access deny !login<br>
>=C2=A0 =C2=A0 http_access deny login !all<br>
> behave equally. Are there any subtle differences in how they work?<br>
> <br>
<br>
No Credentials:<br>
=C2=A0 - both will trigger auth (needed to test "login").<br>
<br>
Good Credentails:<br>
=C2=A0 - both will skip (line as a whole is a non-match)<br>
<br>
Bad credentials:<br>
=C2=A0 - First will match, "login" being last triggers a re-auth.=
<br>
=C2=A0 - 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) f=
or <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>
=C2=A0 =C2=A0acl nologin req_header Proxy-Authorization .<br>
=C2=A0 =C2=A0http_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>
--0000000000000822d8064dd94160--
--===============8151014956301393872==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
squid-users mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-users
--===============8151014956301393872==--