On 5/05/20 4:31 am, Alex Rousskov wrote: > 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. > We do not save the CONNECT tunnel message objects in the TLS handshake state objects. As such the state needed by dstdomain is not available during ssl_bump ACL processing. Only state from the TCP connection and the underway TLS handshake are guaranteed to be available to the ssl_bump ACLs. Anything else is best-effort. At least that was the situation when that documentation was written. The bugs we have about other CONNECT state not being available are still open so I doubt the situation has changed even with the more recent refactoring. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
