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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
