[squid-users] req_header acl with ssl_bump

[Alex Rousskov]

On 12/7/22 16:26, Toler, Matt wrote:
> Hello,
> 
> We are attempting to leverage headers to isolate access to external 
> sites with squid 4.14. The Loadbalencer is injecting headers and squid 
> is simply verifying them:
> 
> acl ACL_HDR_1 req_header Repo_Svr_VerifiedHdr True 
> acl REPO_DST_ALLOW dstdomain "/etc/squid/acls.d/hosts.acl" 
> http_access allow PROXY-SRC REPO_DST_ALLOW ACL_HDR_1
> 
> We are currently decrypting this traffic and it’s working well.
> 
> Now we have a requirement to skip ssl decrypt for only certain 
> destinations. My thought was to simply create a separate ACL where 
> skipping ssl decrypt is required and add the header ACL to the end of 
> the ssl_bump directive like so:
> 
> acl Repo_Skip_HDR req_header Repo_Svr_VerifiedHdr True 
> acl Repo_SkipSslDecrypt dstdomain "/etc/squid/acls.d/hosts.acl" 
> ssl_bump none Repo_SkipSslDecrypt Repo_Skip_HDR
> 
> This parsed successfully but did not have the desired effect. The squid 
> is still inspecting the traffic even with the header present as we can 
> see in the logs. Making things a little more complex, the ssl_bump 
> directive seems to have a global effect

I am not sure what you mean by "global effect". The ssl_bump directive 
affects transactions that are received on ports marked with an 
"ssl-bump" option and only them.


> and also imply “http_access allow” 

There is no such implication. In fact, conflating ssl_bump rules and 
HTTP-level access controls is a common configuration mistake. Correct 
configurations treat those two areas separately.

The only case where one could see a legitimate intersection of SslBump 
and access-controls is an "ssl_bump terminate" rule that triggers TCP 
connection(s) closure. One can view that termination as a form of access 
control (at TCP rather than HTTP level) -- http_access rules are not 
evaluated after Squid closes the connections, of course. In all other 
cases, http_access rules are evaluated after every ssl_bump rules scan. 
For more information, see 
https://wiki.squid-cache.org/Features/SslPeekAndSplice


> making it difficult isolate access. To get around this I thought 
> to simply skip ssl decrypt for the traffic with verified headers:
> 
> acl Repo_Skip_HDR req_header Repo_Svr_VerifiedHdr True
> 
> ssl_bump none Repo_Skip_HDR
> 
> Unfortunately even this isn’t working, again the config checks out and 
> runs happily, we see the header in the logs, but squid still tries to 
> inspect the traffic.
> 
> Any thoughts on why ssl_bump would ignore the header ACL or other 
> suggestions to isolate traffic when being required to skip ssl decrypt 
> would be greatly appreciated.

SslBump acts on the first applicable matching rule. It sounds like your 
(unsupported legacy) "none" rule is located below some other ssl_bump 
rules that are applicable to the current SslBump step and that match at 
least once. For more information, see 
https://wiki.squid-cache.org/Features/SslPeekAndSplice
  You can (indirectly and partially) test that theory by making the 
ssl_bump "none" rule the very first ssl_bump rule in the entire Squid 
configuration. Assuming all CONNECT requests have the right headers, 
that ssl_bump "none" rule should match as appropriate, and Squid should 
establish a blind TCP tunnel instead of doing TLS.

In modern configurations, the correct action is "splice", not "none". 
The above SslPeekAndSplice page documents the difference.


HTH,

Alex.