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 <[email protected]> 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, 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==--