<!DOCTYPE html> <html data-lt-installed="true"> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body style="padding-bottom: 1px;"> <div class="markdown-here-wrapper"> <h2>Summary</h2> The <code>proxy_auth -i</code> ACL (case-insensitive user matching) is broken in Squid 6.x. The <code>-i</code> flag causes entries to be lowercased during parse, but the internal set container retains a case-sensitive comparator, so lookups with mixed-case usernames always fail. <code>proxy_auth_regex -i</code> and <code>proxy_auth</code> (without <code>-i</code>) work correctly. <h2>Squid Version</h2> <ul> <li>Affected: Squid 6.14-VCS (likely all Squid 6.x versions)</li> <li>Working: Squid 5.x (tested, <code>-i</code> works correctly)</li> </ul> <h2>Operating System</h2> <ul> <li>Debian-based Linux (Artica Proxy appliance)</li> </ul> <h2>Steps to Reproduce</h2> <ol> <li> Configure a negotiate (SPNEGO/NTLM) authentication helper that returns usernames in mixed case (e.g., <code>DOMAIN/Username</code>) </li> <li> Create an ACL user list file <code>/etc/squid3/acls/userlist.txt</code>: <pre><code>DOMAIN/username DOMAIN/Username </code></pre> </li> <li> Configure <code>proxy_auth -i</code> ACL: <pre><code>acl BlockedUsers proxy_auth -i "/etc/squid3/acls/userlist.txt" http_access deny BlockedUsers </code></pre> </li> <li> Authenticate via negotiate helper. The helper returns: <code>AF oQcwBaADCgEA DOMAIN/Username</code> </li> <li> Expected: <code>proxy_auth -i</code> matches <code>DOMAIN/Username</code> against <code>domain/username</code> (case-insensitive) → access denied </li> <li> Actual: <code>proxy_auth -i</code> does NOT match → access allowed </li> </ol> <h2>Workarounds</h2> Any of these work: <ul> <li>Use <code>proxy_auth</code> without <code>-i</code>, ensuring the ACL file contains usernames in the exact case returned by the helper</li> <li>Use <code>proxy_auth_regex -i</code> instead (regex matching handles case-insensitivity correctly)</li> </ul> <h2>Root Cause Analysis</h2> The bug is in <code>src/acl/UserData.cc</code>. In Squid 6.x, the <code>-i</code> flag was refactored into an ACL “line option” (handled by <code>lineOptions()</code>/<code>Acl::BooleanOptionValue</code>). The <code>-i</code> token is consumed by the line options parser before <code>parse()</code> is called. However, the <code>parse()</code> function only recreates the internal <code>std::set</code> with a case-insensitive comparator when it sees <code>-i</code> as a token — which never happens in Squid 6.x because the token was already consumed. <h3>Code trace in <code>UserData.cc</code>:</h3> Constructor — set defaults to case-sensitive: <pre><code class="hljs language-cpp">ACLUserData::ACLUserData() : userDataNames(CaseSensitiveSBufCompare) // case-SENSITIVE by default { ... } </code></pre> parse() — the set is never recreated: <pre><code class="hljs language-cpp">void ACLUserData::parse() { // Step 1: flag is set correctly from the line option flags.case_insensitive = bool(CaseInsensitive_); // TRUE (from -i line option) char *t = nullptr; if ((t = ConfigParser::strtokFile())) { SBuf s(t); // Step 2: this check NEVER matches in Squid 6.x because // "-i" was already consumed by the line options parser if (s.cmp("-i",2) == 0) { flags.case_insensitive = true; // THIS BLOCK NEVER EXECUTES — the set is never recreated UserDataNames_t newUdn(CaseInsensitveSBufCompare); newUdn.insert(userDataNames.begin(), userDataNames.end()); swap(userDataNames, newUdn); } else { // Step 3: entries ARE correctly lowercased... if (flags.case_insensitive) s.toLower(); // ...but inserted into a case-SENSITIVE set! userDataNames.insert(s); } } // ... (remaining entries also lowercased and inserted into case-sensitive set) } </code></pre> match() — lookup uses case-sensitive comparison on lowercase entries: <pre><code class="hljs language-cpp">bool ACLUserData::match(char const *user) { // user = "DOMAIN/Username" (original case from auth helper) // userDataNames contains "domain/username" (lowercased during parse) // userDataNames comparator = CaseSensitiveSBufCompare (never changed!) bool result = (userDataNames.find(SBuf(user)) != userDataNames.end()); // find("DOMAIN/Username") in set{"domain/username"} with CASE-SENSITIVE compare // → NOT FOUND (because "DOMAIN/Username" != "domain/username") return result; // returns false — BUG } </code></pre> <h3>In Squid 5.x (working correctly):</h3> In Squid 5.x, <code>-i</code> was passed through to <code>parse()</code> as a regular token. So the <code>if (s.cmp("-i",2) == 0)</code> block DID execute, and the set was properly recreated with <code>CaseInsensitveSBufCompare</code>. The case-insensitive comparator made <code>find()</code> work regardless of case. In Squid 6.x, <code>-i</code> was refactored into a generic ACL “line option” — it is now consumed by the line options parser before <code>parse()</code> is called. The flag value is correctly propagated to <code>CaseInsensitive_</code> (and then to <code>flags.case_insensitive</code>), and entries are correctly lowercased during insertion. However, the set comparator is never switched from case-sensitive to case-insensitive because the code path that does this (<code>if (s.cmp("-i",2) == 0)</code>) is never reached. <h2>Debug Evidence</h2> <h3>Squid 6.14-VCS debug output (<code>debug_options ALL,1 28,9 29,9 84,9</code>):</h3> ACL parsing — entries correctly lowercased, 2 unique users: <pre><code>UserData.cc(93) parse: parsing user list UserData.cc(99) parse: first token is CHILD01/administrator UserData.cc(116) parse: Adding user child01/administrator UserData.cc(121) parse: Case-insensitive-switch is 1 UserData.cc(124) parse: parsing following tokens UserData.cc(128) parse: Got token: <a class="moz-txt-link-abbreviated" href="mailto:administrator@abolinhas.lab">administrator@abolinhas.lab</a> UserData.cc(133) parse: Adding user <a class="moz-txt-link-abbreviated" href="mailto:administrator@abolinhas.lab">administrator@abolinhas.lab</a> UserData.cc(128) parse: Got token: <a class="moz-txt-link-abbreviated" href="mailto:Administrator@abolinhas.lab">Administrator@abolinhas.lab</a> UserData.cc(133) parse: Adding user <a class="moz-txt-link-abbreviated" href="mailto:administrator@abolinhas.lab">administrator@abolinhas.lab</a> UserData.cc(128) parse: Got token: CHILD01/Administrator UserData.cc(133) parse: Adding user child01/administrator UserData.cc(142) parse: ACL contains 2 users </code></pre> Helper response — username correctly extracted: <pre><code>helper.cc(1122) helperStatefulHandleRead: accumulated[38]=AF oQcwBaADCgEA CHILD01/Administrator Reply.cc(43) finalize: Parsing helper buffer UserRequest.cc(267) HandleReply: got reply={result=OK, notes={token: oQcwBaADCgEA; user: CHILD01/Administrator; }} UserRequest.cc(338) HandleReply: authenticated user CHILD01/Administrator UserRequest.cc(357) HandleReply: Successfully validated user via Negotiate. Username 'CHILD01/Administrator' </code></pre> Match with <code>-i</code> — FAILS (BUG): <pre><code>UserData.cc(26) match: user is CHILD01/Administrator, case_insensitive is 1 UserData.cc(37) match: returning 0 </code></pre> Match without <code>-i</code> — WORKS (proves the issue is with <code>-i</code>): <pre><code>UserData.cc(26) match: user is CHILD01/Administrator, case_insensitive is 0 UserData.cc(37) match: returning 1 </code></pre> <h2>Proof of Concept — Full Debug Session</h2> Below is the complete step-by-step debug session performed on a live Squid 6.14-VCS instance to isolate and confirm the bug. <h3>Environment</h3> <ul> <li>Squid server: 192.168.60.58, Squid 6.14-VCS on Debian-based Linux (Artica Proxy)</li> <li>Client machine: 192.168.60.31, Windows 10 domain-joined to <code>CHILD01</code> (child domain of <code>ARTICATECH</code>)</li> <li>Authentication: Negotiate (SPNEGO with NTLM fallback) via external helper</li> <li>Auth helper: Returns <code>AF <blob> CHILD01/Administrator</code> on successful authenticate</li> </ul> <h3>Step 1 — Baseline configuration (broken)</h3> ACL user list file (<code>/etc/squid3/acls/container_963.1.txt</code>): <pre><code>CHILD01/administrator <a class="moz-txt-link-abbreviated" href="mailto:administrator@abolinhas.lab">administrator@abolinhas.lab</a> <a class="moz-txt-link-abbreviated" href="mailto:Administrator@abolinhas.lab">Administrator@abolinhas.lab</a> CHILD01/Administrator </code></pre> File verified clean with <code>xxd</code> — Unix line endings (0x0A), no BOM, no hidden characters: <pre><code>00000000: 4348 494c 4430 312f 6164 6d69 6e69 7374 CHILD01/administ 00000010: 7261 746f 720a 6164 6d69 6e69 7374 7261 rator.administra 00000020: 746f 7240 6162 6f6c 696e 6861 732e 6c61 <a class="moz-txt-link-abbreviated" href="mailto:tor@abolinhas.la">tor@abolinhas.la</a> 00000030: 620a 4164 6d69 6e69 7374 7261 746f 7240 b.Administrator@ 00000040: 6162 6f6c 696e 6861 732e 6c61 620a 4348 abolinhas.lab.CH 00000050: 494c 4430 312f 4164 6d69 6e69 7374 7261 ILD01/Administra 00000060: 746f 720a tor. </code></pre> squid.conf ACL (in <code>/etc/squid3/http_access.conf</code>): <pre><code>acl AnnotateRule587 annotate_transaction accessrule=Rule587 acl Group953 proxy_auth -i "/etc/squid3/acls/container_963.1.txt" http_access deny Group953 AnnotateRule587 all </code></pre> <h3>Step 2 — Enable debug logging</h3> <pre><code class="hljs language-bash"># Set debug options in /etc/squid3/logging.conf debug_options ALL,1 28,9 29,9 84,9 # Section 28 = Access Control (ACL matching, UserData) # Section 29 = Authenticator (negotiate helper handling) # Section 84 = Helper I/O (helper stdin/stdout) squid -k reconfigure </code></pre> <h3>Step 3 — Observe ACL parsing (cache.log)</h3> Squid parses the ACL file with <code>-i</code> enabled. Entries are lowercased during insertion. After case-insensitive deduplication, the ACL contains 2 unique users: <pre><code>2026/03/04 18:23:57.734 kid1| 28,2| UserData.cc(93) parse: parsing user list 2026/03/04 18:23:57.734 kid1| 28,5| UserData.cc(99) parse: first token is CHILD01/administrator 2026/03/04 18:23:57.734 kid1| 28,6| UserData.cc(116) parse: Adding user child01/administrator 2026/03/04 18:23:57.734 kid1| 28,3| UserData.cc(121) parse: Case-insensitive-switch is 1 2026/03/04 18:23:57.734 kid1| 28,4| UserData.cc(124) parse: parsing following tokens 2026/03/04 18:23:57.734 kid1| 28,6| UserData.cc(128) parse: Got token: <a class="moz-txt-link-abbreviated" href="mailto:administrator@abolinhas.lab">administrator@abolinhas.lab</a> 2026/03/04 18:23:57.734 kid1| 28,6| UserData.cc(133) parse: Adding user <a class="moz-txt-link-abbreviated" href="mailto:administrator@abolinhas.lab">administrator@abolinhas.lab</a> 2026/03/04 18:23:57.734 kid1| 28,6| UserData.cc(128) parse: Got token: <a class="moz-txt-link-abbreviated" href="mailto:Administrator@abolinhas.lab">Administrator@abolinhas.lab</a> 2026/03/04 18:23:57.734 kid1| 28,6| UserData.cc(133) parse: Adding user <a class="moz-txt-link-abbreviated" href="mailto:administrator@abolinhas.lab">administrator@abolinhas.lab</a> 2026/03/04 18:23:57.734 kid1| 28,6| UserData.cc(128) parse: Got token: CHILD01/Administrator 2026/03/04 18:23:57.734 kid1| 28,6| UserData.cc(133) parse: Adding user child01/administrator 2026/03/04 18:23:57.734 kid1| 28,4| UserData.cc(142) parse: ACL contains 2 users </code></pre> Observation: <code>Case-insensitive-switch is 1</code> (flag is set correctly), entries are lowercased (<code>child01/administrator</code>, <code><a class="moz-txt-link-abbreviated" href="mailto:administrator@abolinhas.lab">administrator@abolinhas.lab</a></code>). Parsing looks correct. <h3>Step 4 — Client authenticates via Negotiate (NTLM-in-SPNEGO)</h3> Client on 192.168.60.31 sends CONNECT through the proxy. The negotiate helper performs two-step NTLM-in-SPNEGO authentication: Step 4a — NTLM Type 2 challenge (TT response): ``` 2026/03/04 18:29:02.696 kid1| 84,5| helper.cc(1112) helperStatefulHandleRead: helperStatefulHandleRead: 376 bytes from negotiateauthenticator #Hlpr91 2026/03/04 18:29:02.696 kid1| 84,3| Reply.cc(43) finalize: Parsing helper buffer 2026/03/04 18:29:02.696 kid1| 29,8| UserRequest.cc(267) HandleReply: hlpRes693 got reply={result=TT, notes={token: TlRMTVNTUA…AAAA=; }} 2026/03/04 18:29:02.696 kid1| 29,4| UserRequest.cc(313) HandleReply: Need to challenge the client with a server token <pre><code> **Step 4b — NTLM Type 3 validation (AF response):** </code></pre> 2026/03/04 18:29:02.724 kid1| 84,9| helper.cc(1447) helperStatefulDispatch: helperStatefulDispatch busying helper negotiateauthenticator #Hlpr91 2026/03/04 18:29:02.724 kid1| 84,5| helper.cc(1476) helperStatefulDispatch: helperStatefulDispatch: Request sent to negotiateauthenticator #Hlpr91, 764 bytes 2026/03/04 18:29:02.731 kid1| 84,5| helper.cc(1112) helperStatefulHandleRead: helperStatefulHandleRead: 38 bytes from negotiateauthenticator #Hlpr91 2026/03/04 18:29:02.732 kid1| 84,9| helper.cc(1122) helperStatefulHandleRead: accumulated[38]=AF oQcwBaADCgEA CHILD01/Administrator 2026/03/04 18:29:02.732 kid1| 84,3| helper.cc(1134) helperStatefulHandleRead: helperStatefulHandleRead: end of reply found 2026/03/04 18:29:02.732 kid1| 84,3| Reply.cc(43) finalize: Parsing helper buffer 2026/03/04 18:29:02.732 kid1| 84,3| Reply.cc(61) finalize: Buff length is larger than 2 2026/03/04 18:29:02.732 kid1| 29,8| UserRequest.cc(267) HandleReply: hlpRes693 got reply={result=OK, notes={token: oQcwBaADCgEA; user: CHILD01/Administrator; }} 2026/03/04 18:29:02.732 kid1| 29,4| UserRequest.cc(338) HandleReply: authenticated user CHILD01/Administrator 2026/03/04 18:29:02.732 kid1| 29,4| UserRequest.cc(357) HandleReply: Successfully validated user via Negotiate. Username ‘CHILD01/Administrator’ <pre><code> Observation: The helper returns exactly `AF oQcwBaADCgEA CHILD01/Administrator` (38 bytes including newline). Squid correctly parses the reply, extracts the token and username. The authenticated username is set to `CHILD01/Administrator`. ### Step 5 — ACL match with `-i` FAILS (the bug) When Squid evaluates `http_access deny Group953`, it checks the `proxy_auth -i` ACL: </code></pre> 2026/03/04 18:27:58.119 kid1| 28,7| UserData.cc(26) match: user is CHILD01/Administrator, case_insensitive is 1 2026/03/04 18:27:58.119 kid1| 28,7| UserData.cc(37) match: returning 0 <pre><code> **Result: `returning 0` — NO MATCH.** The ACL check for Group953 returns 0 (no match), so the deny rule does not trigger. Access is allowed through the final allow rule: </code></pre> 2026/03/04 18:29:02.732 kid1| 28,5| Acl.cc(145) matches: checking Group953 2026/03/04 18:29:02.732 kid1| 28,3| Acl.cc(172) matches: checked: Group953 = 0 <pre><code> Access log confirms user is NOT denied (note `accessrule: final_allow`): </code></pre> 1772648820.870 75169 192.168.60.31 TCP_TUNNEL/200 5123 CONNECT sapo.pt:443 CHILD01/Administrator HIER_DIRECT/213.13.145.114:443 - accessrule:%20final_allow <pre><code> ### Step 6 — Remove `-i` flag, ACL match SUCCEEDS Changed the ACL definition to remove the `-i` flag: ```bash # Before: acl Group953 proxy_auth -i "/etc/squid3/acls/container_963.1.txt" # After: acl Group953 proxy_auth "/etc/squid3/acls/container_963.1.txt" squid -k reconfigure </code></pre> After the next authentication from the same client: <pre><code>2026/03/04 18:34:11.740 kid1| 28,7| UserData.cc(26) match: user is CHILD01/Administrator, case_insensitive is 0 2026/03/04 18:34:11.740 kid1| 28,7| UserData.cc(37) match: returning 1 </code></pre> Result: <code>returning 1</code> — MATCH! Without <code>-i</code>, entries are stored in original case from the file. The file contains <code>CHILD01/Administrator</code> (line 4) which exactly matches the helper’s username. The deny rule triggers. Access log confirms user IS now denied (note <code>accessrule: Rule587</code> and <code>ERR_ACCESS_DENIED</code>): <pre><code>1772649291.245 12 192.168.60.31 TCP_DENIED/200 0 CONNECT static.foxnews.com:443 CHILD01/Administrator HIER_NONE/-:- - accessrule:%20Rule587 ERR_ACCESS_DENIED 1772649291.188 2 192.168.60.31 NONE_NONE_ABORTED/403 65843 GET <a class="moz-txt-link-freetext" href="https://static.foxnews.com/.../favicon-96x96.png">https://static.foxnews.com/.../favicon-96x96.png</a> CHILD01/Administrator HIER_NONE/-:- text/html ERR_ACCESS_DENIED </code></pre> <h3>Step 7 — Additional confirmation: <code>proxy_auth_regex -i</code> also works</h3> Changing the ACL to use <code>proxy_auth_regex -i</code> with the same file: <pre><code>acl Group953 proxy_auth_regex -i "/etc/squid3/acls/container_963.1.txt" </code></pre> This also correctly matches and denies the user. <code>proxy_auth_regex</code> is unaffected because it uses <code>ACLRegexData</code> (regex matching) instead of <code>ACLUserData</code> (set-based matching). <h3>Step 8 — Downgrade to Squid 5.x confirms fix</h3> After downgrading from Squid 6.14-VCS to Squid 5.x on the same machine, the original configuration with <code>proxy_auth -i</code> works correctly — the deny rule matches and blocks the user as expected. <pre><code class="hljs language-bash"> acl Group953 proxy_auth -i "/etc/squid3/acls/container_963.1.txt" squid -k reconfigure </code></pre> After the next authentication from the same client: <pre><code>2026/03/04 18:34:11.740 kid1| 28,7| UserData.cc(26) match: user is CHILD01/Administrator, case_insensitive is 1 2026/03/04 18:34:11.740 kid1| 28,7| UserData.cc(37) match: returning 1 </code></pre> Result: <code>returning 1</code> — MATCH! On Squd5.X With <code>-i</code>, entries are stored in original case from the file. The file contains <code>CHILD01/Administrator</code> (line 4) which exactly matches the helper’s username. The deny rule triggers. Access log confirms user IS now denied (note <code>accessrule: Rule587</code> and <code>ERR_ACCESS_DENIED</code>): <pre><code>1772649291.245 12 192.168.60.31 TCP_DENIED/200 0 CONNECT static.foxnews.com:443 CHILD01/Administrator HIER_NONE/-:- - accessrule:%20Rule587 ERR_ACCESS_DENIED 1772649291.188 2 192.168.60.31 NONE_NONE_ABORTED/403 65843 GET <a class="moz-txt-link-freetext" href="https://static.foxnews.com/.../favicon-96x96.png">https://static.foxnews.com/.../favicon-96x96.png</a> CHILD01/Administrator HIER_NONE/-:- text/html ERR_ACCESS_DENIED </code></pre> <h3>PoC Summary Table</h3> <table> <thead><tr> <th>Configuration</th> <th align="center">Squid 6.14-VCS</th> <th align="center">Squid 5.x</th> </tr> </thead><tbody> <tr> <td><code>proxy_auth -i</code> (file)</td> <td align="center">BROKEN</td> <td align="center">Works</td> </tr> <tr> <td><code>proxy_auth</code> (no <code>-i</code>, file)</td> <td align="center">Works</td> <td align="center">Works</td> </tr> <tr> <td><code>proxy_auth_regex -i</code> (file)</td> <td align="center">Works</td> <td align="center">Works</td> </tr> </tbody> </table> <h2>Suggested Fix</h2> Either of these approaches would fix the bug: <h3>Option A: Recreate the set when <code>CaseInsensitive_</code> is set (in <code>parse()</code>)</h3> Add set recreation at the beginning of <code>parse()</code> when the flag comes from the line option: <pre><code class="hljs language-cpp">void ACLUserData::parse() { flags.case_insensitive = bool(CaseInsensitive_); // If case-insensitive was set via line option, ensure the set // uses the case-insensitive comparator if (flags.case_insensitive) { UserDataNames_t newUdn(CaseInsensitveSBufCompare); newUdn.insert(userDataNames.begin(), userDataNames.end()); std::swap(userDataNames, newUdn); } // ... rest of parse() unchanged } </code></pre> <h3>Option B: Lowercase the search key in <code>match()</code></h3> <pre><code class="hljs language-cpp">bool ACLUserData::match(char const *user) { debugs(28, 7, "user is " << user << ", case_insensitive is " << flags.case_insensitive); if (user == nullptr || strcmp(user, "-") == 0) return 0; if (flags.required) { debugs(28, 7, "aclMatchUser: user REQUIRED and auth-info present."); return 1; } SBuf key(user); if (flags.case_insensitive) key.toLower(); bool result = (userDataNames.find(key) != userDataNames.end()); debugs(28, 7, "returning " << result); return result; } </code></pre> Option A is more correct because it also fixes the set comparator for any future operations. Option B is simpler but relies on both sides being lowercased rather than using a proper case-insensitive comparator. <h2>Configuration Context</h2> This was observed with a negotiate (SPNEGO/Kerberos with NTLM fallback) authentication helper. The helper returns usernames in mixed case as received from Active Directory SSPI (e.g., <code>DOMAIN/Username</code>). The <code>proxy_auth -i</code> ACL should match these usernames case-insensitively against the ACL file entries, but fails to do so in Squid 6.x. <pre><code>auth_param negotiate program /path/to/negotiate-helper acl BlockedUsers proxy_auth -i "/path/to/userlist.txt" http_access deny BlockedUsers </code></pre> </div> </body> </html>