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

Jonathan Lee <[email protected]> Thu, 5 Mar 2026 08:12:19 -0800
Newsgroups gmane.comp.web.squid.general
Message-ID <[email protected]>
--===============6209646304441235793==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8E1DDA41-F808-471C-B67E-90820AE8CDEB"


--Apple-Mail=_8E1DDA41-F808-471C-B67E-90820AE8CDEB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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-based 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 =
handled.

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:
>=20
> 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
>=20
> 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 between the transactions.
>=20
>=20
>> 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:
>=20
> This is not great since group is not limited to Negotiate and NTLM =
authentication types. Other auth schemes have group only being valid on =
one HTTP transaction.
>=20
>=20
> 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.
>=20
> HTH
> Amos
>=20
> _______________________________________________
> squid-users mailing list
> [email protected]
> https://lists.squid-cache.org/listinfo/squid-users


--Apple-Mail=_8E1DDA41-F808-471C-B67E-90820AE8CDEB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dus-ascii"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><p>Hi,</p><p>I wanted to provide an =
overview of how the client ACL annotation and SSL bump logic is =
structured in the configuration.</p><p>First, an IPv6 subnet ACL is =
defined to identify internal client traffic:</p><pre><code>acl =
splice_ipv6 src 2001: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 =
defined using a combination of IP-based and MAC-based ACLs. Each device =
entry includes:</p><ul><li><p>An IPv4 address</p></li><li><p>An IPv6 =
address (when applicable)</p></li><li><p>A MAC =
address</p></li></ul><p>Example:</p><pre><code># 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 =
apply 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 =
intercepted for inspection:</p><pre><code>acl bump_main all-of =
bump_only_mac bump_only_ip
</code></pre><p>Additional grouped ACL logic is used to determine when =
traffic 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 apply only to recognized =
connections:</p><pre><code>acl active_use annotate_client active=3Dtrue
</code></pre><p>This annotation is referenced later in the SSL bump =
rules to 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><pre><code>ssl_bump terminate terminate_group
</code></pre><p>Traffic matching splice conditions is allowed to pass =
through without interception:</p><pre><code>ssl_bump splice splice_main =
active_use
</code></pre><p>Traffic from devices configured for inspection is then =
processed 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 =
annotation or ACL conditions is terminated:</p><pre><code>acl activated =
note active_use true
ssl_bump terminate !activated
</code></pre><p>This ensures that only properly identified and permitted =
client connections are allowed through the proxy.</p><p>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.</p><p>Best regards,</p><p><br></p><p>Joanthan =
Lee</p><div><br><blockquote type=3D"cite"><div>On Mar 4, 2026, at 23:23, =
Amos Jeffries &lt;[email protected]&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><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}note<br></blockquote><br>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 between the =
transactions.<br><br><br><blockquote type=3D"cite">2. How do you =
think,&nbsp;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:<br></blockquote><br>This is not great since group is not limited =
to Negotiate and NTLM authentication types. Other auth schemes have =
group only being valid on one HTTP transaction.<br><br><br>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.<br><br>HTH<br>Amos<br><br>_______________________________________=
________<br>squid-users mailing =
list<br>[email protected]<br>https://lists.squid-cache.org=
/listinfo/squid-users<br></div></div></blockquote></div><br></body></html>=

--Apple-Mail=_8E1DDA41-F808-471C-B67E-90820AE8CDEB--

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

--===============6209646304441235793==--