[squid-users] Best way to prevent squid from bumping CONNECTs

[Alex Rousskov]

On 5/3/20 10:41 PM, Scott wrote:

> acl tcp_open_connect_sslbump at_step SslBump1
> acl ssl_splice_sni ssl::server_name "/usr/local/etc/squid/acls/splice_sni"
> acl guest_net_src src x.y.z.0/24
> 
> ssl_bump peek tcp_open_connect_sslbump
> ssl_bump splice ssl_splice_sni
> ssl_bump bump guest_net_src
> ssl_bump splice


> where I splice instead of bump for destinations that are often used with 
> certificate pinning software (.apple.com with iOS for example).


> https://wiki.squid-cache.org/Features/SslPeekAndSplice says "At no point 
> during ssl_bump processing will dstdomain ACL work".

I have not tested this, but I would expect the dstdomain ACL to work
during SslBump steps using the destination address from the (real or
fake) CONNECT request URI. It is possible that, for the author of that
wiki statement, that kind of functionality is equivalent to "not work",
but I personally would not phrase it that way.


> Does that also imply that `ssl::server_name' won't work
> for `http_access' statements?

No, it does not. Both ACLs should "work". Naturally, both ACLs have
their own limitations and intended purposes. If you find problems with
their documentation in squid.conf.documented (or want to improve it),
please consider filing a bug report (or submitting a pull request). You
can also improve the wiki page, of course, but I recommend coordinating
with the paragraph author before changing that paragraph:

https://wiki.squid-cache.org/action/diff/Features/SslPeekAndSplice?action=diff&rev1=19&rev2=20



> I have config like this:

> acl no_proxy_dstdomain dstdomain "/usr/local/etc/squid/acls/no_proxy_dstdomain"
> http_access deny no_proxy_dstdomain
> acl no_proxy_sni ssl::server_name "/usr/local/etc/squid/acls/no_proxy_dstdomain"
> http_access deny no_proxy_sni

> Are the last two lines redundant?

I bet there are transactions (or transaction processing steps) that
either one of the two ACLs will match while the other will not, but I
have not studied this in detail.


> Or are they required for spliced connections?

"Required" may be too strong of a word because, as you said below, you
can probably accomplish similar outcome using terminate rules. However,
the details of that outcome would differ, so I can imagine that
http_access is the right or the best approach in _some_ cases.


> Or should I just convert those lines into ssl_bump terminate no_proxy_sni ?

A matching "http_access deny" forces Squid to generate an HTTP error
response. If that happens during SslBump processing, the connection with
the client will be bumped (in hope) to deliver that response. If such
bumping is no longer possible, I am not sure what happens, but I would
expect Squid to close the underlying TLS/TCP connection.

A matching "ssl_bump terminate" rule closes the client TLS/TCP
connection without generating an HTTP error response. It can only match
during SslBump processing.

Use appropriate rule(s) to accomplish what you actually want to
accomplish. And test that your expectations match what Squid is doing.

I apologize that I cannot give simpler yes/no answers to your
(implicitly loaded) questions. I hope the above responses give you
enough information to find the answers you are looking for.


> And finally, I want to use a different outgoing tcp address for intercepted 
> connections.  What's the best ACL to match those?  Or should I just match 
> explicit proxy connections by port? (ie !myport 3128)

I would start by testing the myportname ACL(s).


HTH,

Alex.