Re: Using AD groups from negotiate_kerberos_auth in ssl-bumped connections.

--===============5149695997067456748==
Content-Type: multipart/alternative; boundary="00000000000065cb93064dc32111"

--00000000000065cb93064dc32111
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Alex,

> I would suggest using "clt_conn_tag" annotation for that purpose. That
> annotation was specifically added to address similar use cases.
>
> If really needed, your helper can send both "group" and "clt_conn_tag"
> annotations. The latter should be copied to subsequent requests received
> on the same client-Squid connection.

I conducted several tests and found that when the authentication helper
returns multiple groups in the 'clt_conn_tag' attributes, all of them are
available only during the initial CONNECT transaction. In subsequent
transactions, only the first group remains available.

Details:
I'm tracking 'clt_conn_tag' via logs:
   logformat my-squid %rm group=3D%note{group}
clt_conn_tag=3D%note{clt_conn_tag}
Example of the BasicAuth-helper:
  #!/bin/bash
  while read -r user pass; do
    echo "OK user=3Duser1 group=3Dgroup1 group=3Dgroup2 clt_conn_tag=3Dgrou=
p1
clt_conn_tag=3Dgroup2"
  done

Single curl request logs:
  CONNECT group=3Dgroup1,group2 clt_conn_tag=3Dgroup1,group2
  GET group=3D- clt_conn_tag=3Dgroup1

Is this the expected behaviour?

Kind regards,
    Ankor.


=D1=87=D1=82, 5 =D0=BC=D0=B0=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 19:12, Jona=
than Lee <[email protected]>:

> Hi,
>
> I wanted to provide an overview of how the client ACL annotation and SSL
> bump logic is structured in the configuration.
>
> First, an IPv6 subnet ACL is defined to identify internal client traffic:
>
> acl splice_ipv6 src 2001:db8:abcd:1::/64
>
> This allows the proxy to recognize devices originating from the internal
> IPv6 network.
>
> Individual client devices are then defined using a combination of IP-base=
d
> and MAC-based ACLs. Each device entry includes:
>
>    -
>
>    An IPv4 address
>    -
>
>    An IPv6 address (when applicable)
>    -
>
>    A MAC address
>
> Example:
>
> # Example Mobile Device
> acl splice_only_ip src 192.168.10.8
> acl splice_only_ip src 2001:db8:abcd:1:192:168:10:8
> acl splice_only_mac arp aa:bb:cc:dd:ee:01
>
> Using both IP and MAC matching helps ensure that rules apply only to the
> intended device.
>
> Devices are grouped based on how their encrypted traffic should be handle=
d.
>
> Splice-only devices are allowed to pass encrypted traffic through the
> proxy without TLS interception:
>
> acl splice_only_local_group all-of splice_only_mac splice_only_ip
>
> Bump-only devices are allowed to have their TLS traffic intercepted for
> inspection:
>
> acl bump_main all-of bump_only_mac bump_only_ip
>
> Additional grouped ACL logic is used to determine when traffic should be
> spliced instead of inspected:
>
> acl splice_group any-of https_login NoBumpDNS NoSSLIntercept
> acl splice_main any-of splice_group splice_only_local_group splice_ipv6
>
> Traffic will be spliced if it matches login-related sites, domains listed
> in the no-bump configuration lists, DNS exclusions, devices specifically
> designated as splice-only, or the internal IPv6 subnet.
>
> Client annotation is used to mark active clients so that SSL bump rules
> apply only to recognized connections:
>
> acl active_use annotate_client active=3Dtrue
>
> This annotation is referenced later in the SSL bump rules to ensure that
> only annotated clients proceed through the inspection logic.
>
> The SSL bump process is implemented in stages.
>
> First, the proxy performs an initial peek at the TLS handshake:
>
> ssl_bump peek step1
>
> Administrative infrastructure addresses are always excluded from
> interception to avoid certificate mismatch issues:
>
> acl no_bump_gateway dst 192.168.10.1
> acl no_bump_gateway dst 2001:db8:abcd:1::1
>
> Blocked or restricted traffic groups are terminated:
>
> ssl_bump terminate terminate_group
>
> Traffic matching splice conditions is allowed to pass through without
> interception:
>
> ssl_bump splice splice_main active_use
>
> Traffic from devices configured for inspection is then processed with SSL
> bump:
>
> ssl_bump bump bump_main active_use
>
> Finally, any traffic that does not meet the expected annotation or ACL
> conditions is terminated:
>
> acl activated note active_use true
> ssl_bump terminate !activated
>
> This ensures that only properly identified and permitted client
> connections are allowed through the proxy.
>
> The configuration also includes performance tuning settings such as SSL
> session caching, persistent client and server connections, optimized
> timeouts for large downloads, DNS timeout adjustments, and memory pool
> limits. These settings are intended to improve proxy efficiency and
> connection stability while maintaining the defined TLS handling policies.
>
> Best regards,
>
>
> Joanthan Lee
>
> On Mar 4, 2026, at 23:23, Amos Jeffries <[email protected]> wrote:
>
> On 04/03/2026 19:33, Andrey K wrote:
>
> Hello, Amos,
> Thanks for the information.
> Canyou alsotellme:
> 1. Is it possible to use a macro in the annotate_client ACL to copy HTTP
> request notes to a TCP connection? Something like:
> acl annotate_groups annotate_client groups=3D%{group}note
>
>
> That is not supported. Which is what I meant by these having to be
> configured manually. You need an ACL to match the group note, and another
> to set the new note, repeated for each group name you want to link betwee=
n
> the transactions.
>
>
> 2. How do you think, should we process the "group" attribute at the
> connection state level as we do with the "clt_conn_tag"? I think this can
> be easily implemented in the UpdateRequestNotes() function (src/
> HttpRequest.cc) by simply copying and pasting a few lines of code:
>
>
> This is not great since group is not limited to Negotiate and NTLM
> authentication types. Other auth schemes have group only being valid on o=
ne
> HTTP transaction.
>
>
> I would suggest having a new access control directive that permits or
> denies annotations to be mapped when the CONNECT is bumped. That would
> allow any existing annotation of the CONNECT transaction to be applied as=
 a
> connection-annotation for the bump'ed request.
>
> HTH
> Amos
>
> _______________________________________________
> squid-users mailing list
> [email protected]
> https://lists.squid-cache.org/listinfo/squid-users
>
>
> _______________________________________________
> squid-users mailing list
> [email protected]
> https://lists.squid-cache.org/listinfo/squid-users
>

--00000000000065cb93064dc32111
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello Alex,<br><div><br></div><div>&gt; I would suggest us=
ing &quot;clt_conn_tag&quot; annotation for that purpose. That<br>&gt; anno=
tation was specifically added to address similar use cases.<br>&gt;=C2=A0<b=
r>&gt; If really needed, your helper can send both &quot;group&quot; and &q=
uot;clt_conn_tag&quot;<br>&gt; annotations. The latter should be copied to =
subsequent requests received<br>&gt; on the same client-Squid connection.</=
div><div><br></div><div>I conducted several tests and found that when the a=
uthentication helper returns multiple groups in the &#39;clt_conn_tag&#39; =
attributes, all of them are available only during the initial CONNECT trans=
action. In subsequent transactions, only the first group remains available.=
</div><div><br></div><div>Details:</div><div><div>I&#39;m tracking &#39;<fo=
nt face=3D"monospace">clt_conn_tag</font>&#39; via=C2=A0logs:</div></div><d=
iv><font face=3D"monospace">=C2=A0 =C2=A0logformat my-squid %rm group=3D%no=
te{group} clt_conn_tag=3D%note{clt_conn_tag}</font></div><div>Example of th=
e BasicAuth-helper:</div><div><font face=3D"monospace">=C2=A0 #!/bin/bash<b=
r>=C2=A0 while read -r user pass; do<br>=C2=A0 =C2=A0 echo &quot;OK user=3D=
user1 group=3Dgroup1 group=3Dgroup2 clt_conn_tag=3Dgroup1 clt_conn_tag=3Dgr=
oup2&quot;<br>=C2=A0 done<br></font></div><div><br></div><div>Single curl r=
equest logs:</div><div><font face=3D"monospace">=C2=A0 CONNECT group=3Dgrou=
p1,group2 clt_conn_tag=3Dgroup1,group2<br>=C2=A0 GET group=3D- clt_conn_tag=
=3Dgroup1<br></font></div><div><br></div><div>Is this the expected behaviou=
r?</div><div><br></div><div>Kind=C2=A0regards,</div><div>=C2=A0 =C2=A0 Anko=
r.</div><div><br></div></div><br><div class=3D"gmail_quote gmail_quote_cont=
ainer"><div dir=3D"ltr" class=3D"gmail_attr">=D1=87=D1=82, 5 =D0=BC=D0=B0=
=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 19:12, Jonathan Lee &lt;<a href=3D"mail=
to:[email protected]">[email protected]</a>&gt;:<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"><div><p>Hi,</p><p>I wanted t=
o provide an overview of how the client ACL annotation and SSL bump logic i=
s structured in the configuration.</p><p>First, an IPv6 subnet ACL is defin=
ed to identify internal client traffic:</p><pre><code>acl splice_ipv6 src 2=
001:db8:abcd:1::/64
</code></pre><p>This allows the proxy to recognize devices originating from=
 the internal IPv6 network.</p><p>Individual client devices are then define=
d using a combination of IP-based and MAC-based ACLs. Each device entry inc=
ludes:</p><ul><li><p>An IPv4 address</p></li><li><p>An IPv6 address (when a=
pplicable)</p></li><li><p>A MAC address</p></li></ul><p>Example:</p><pre><c=
ode># Example Mobile Device
acl splice_only_ip src 192.168.10.8
acl splice_only_ip src 2001:db8:abcd:1:192:168:10:8
acl splice_only_mac arp aa:bb:cc:dd:ee:01
</code></pre><p>Using both IP and MAC matching helps ensure that rules appl=
y only to the intended device.</p><p>Devices are grouped based on how their=
 encrypted traffic should be handled.</p><p>Splice-only devices are allowed=
 to pass encrypted traffic through the proxy without TLS interception:</p><=
pre><code>acl splice_only_local_group all-of splice_only_mac splice_only_ip
</code></pre><p>Bump-only devices are allowed to have their TLS traffic int=
ercepted for inspection:</p><pre><code>acl bump_main all-of bump_only_mac b=
ump_only_ip
</code></pre><p>Additional grouped ACL logic is used to determine when traf=
fic should be spliced instead of inspected:</p><pre><code>acl splice_group =
any-of https_login NoBumpDNS NoSSLIntercept
acl splice_main any-of splice_group splice_only_local_group splice_ipv6
</code></pre><p>Traffic will be spliced if it matches login-related sites, =
domains listed in the no-bump configuration lists, DNS exclusions, devices =
specifically designated as splice-only, or the internal IPv6 subnet.</p><p>=
Client annotation is used to mark active clients so that SSL bump rules app=
ly only to recognized connections:</p><pre><code>acl active_use annotate_cl=
ient active=3Dtrue
</code></pre><p>This annotation is referenced later in the SSL bump rules t=
o ensure that only annotated clients proceed through the inspection logic.<=
/p><p>The SSL bump process is implemented in stages.</p><p>First, the proxy=
 performs an initial peek at the TLS handshake:</p><pre><code>ssl_bump peek=
 step1
</code></pre><p>Administrative infrastructure addresses are always excluded=
 from interception to avoid certificate mismatch issues:</p><pre><code>acl =
no_bump_gateway dst 192.168.10.1
acl no_bump_gateway dst 2001:db8:abcd:1::1
</code></pre><p>Blocked or restricted traffic groups are terminated:</p><pr=
e><code>ssl_bump terminate terminate_group
</code></pre><p>Traffic matching splice conditions is allowed to pass throu=
gh without interception:</p><pre><code>ssl_bump splice splice_main active_u=
se
</code></pre><p>Traffic from devices configured for inspection is then proc=
essed with SSL bump:</p><pre><code>ssl_bump bump bump_main active_use
</code></pre><p>Finally, any traffic that does not meet the expected annota=
tion or ACL conditions is terminated:</p><pre><code>acl activated note acti=
ve_use true
ssl_bump terminate !activated
</code></pre><p>This ensures that only properly identified and permitted cl=
ient connections are allowed through the proxy.</p><p>The configuration als=
o includes performance tuning settings such as SSL session caching, persist=
ent client and server connections, optimized timeouts for large downloads, =
DNS timeout adjustments, and memory pool limits. These settings are intende=
d to improve proxy efficiency and connection stability while maintaining th=
e defined TLS handling policies.</p><p>Best regards,</p><p><br></p><p>Joant=
han Lee</p><div><br><blockquote type=3D"cite"><div>On Mar 4, 2026, at 23:23=
, Amos Jeffries &lt;<a href=3D"mailto:[email protected]" target=3D"_blan=
k">[email protected]</a>&gt; wrote:</div><br><div><div>On 04/03/2026 19:=
33, Andrey K wrote:<br><blockquote type=3D"cite">Hello, Amos,<br>Thanks for=
 the information.<br>Canyou alsotellme:<br>1. Is it possible to use a macro=
 in the annotate_client ACL to copy HTTP request notes to a TCP connection?=
 Something like:<br>acl annotate_groups annotate_client groups=3D%{group}no=
te<br></blockquote><br>That is not supported. Which is what I meant by thes=
e having to be configured manually. You need an ACL to match the group note=
, and another to set the new note, repeated for each group name you want to=
 link between the transactions.<br><br><br><blockquote type=3D"cite">2. How=
 do you think,=C2=A0should we process the &quot;group&quot; attribute at th=
e connection state level as we do with the &quot;clt_conn_tag&quot;? I thin=
k this can be easily implemented in the UpdateRequestNotes() function (src/=
 HttpRequest.cc) by simply copying and pasting a few lines of code:<br></bl=
ockquote><br>This is not great since group is not limited to Negotiate and =
NTLM authentication types. Other auth schemes have group only being valid o=
n one HTTP transaction.<br><br><br>I would suggest having a new access cont=
rol directive that permits or denies annotations to be mapped when the CONN=
ECT is bumped. That would allow any existing annotation of the CONNECT tran=
saction to be applied as a connection-annotation for the bump&#39;ed reques=
t.<br><br>HTH<br>Amos<br><br>______________________________________________=
_<br>squid-users mailing list<br><a href=3D"mailto:[email protected]=
cache.org" target=3D"_blank">[email protected]</a><br><a hr=
ef=3D"https://lists.squid-cache.org/listinfo/squid-users" target=3D"_blank"=
>https://lists.squid-cache.org/listinfo/squid-users</a><br></div></div></bl=
ockquote></div><br></div>_______________________________________________<br=
>
squid-users mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">squi=
[email protected]</a><br>
<a href=3D"https://lists.squid-cache.org/listinfo/squid-users" rel=3D"noref=
errer" target=3D"_blank">https://lists.squid-cache.org/listinfo/squid-users=
</a><br>
</blockquote></div>

--00000000000065cb93064dc32111--

--===============5149695997067456748==
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

--===============5149695997067456748==--