> Date: Mon, 27 Apr 2020 15:09:03 -0400 > From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: Best way to prevent squid from bumping CONNECTs > > On 4/27/20 12:21 PM, Scott wrote: > > > my experience with ssl_bump is that it tries to bump SSL connections whether > > presented to Squid explicitly or implicitly. > > * For http_port configured with an ssl-bump flag, HTTP CONNECT tunnels > are sent to the SslBump code. > > * For https_port configured with an ssl-bump flag, all traffic is sent > to the SslBump code (by faking a corresponding HTTP CONNECT request). > Indeed. I have ssl-bump on both my http_port and https_port (intercept). These `fake' CONNECT requests I assume only contain the IP address of the upstream server, not the hostname, as intercepted SSL connections are TCP OPENs. Am I right then in saying that using ssl::server_name is useless for bumped intercepted connections? (Even if Squid did reverse proxy the IP it would be fairly unreliable). > > Because not all CONNECT sessions are SSL, if the CONNECT destination does > > not begin a TLS handshake will Squid revert to simply creating a TCP > > tunnel instead of bumping? > > SslBump expects SSL/TLS traffic inside CONNECT tunnels that it is > configured to inspect. If an inspecting Squid decides that it got some > other traffic, Squid follows the on_unsupported_protocol configuration. Thanks, I was unaware of that option. > > My workaround has been to simply add `!CONNECT' to the `ssl_bump > > host_acl' statements. Squid will happily bump the SSL sessions and proxy > > the CONNECT sessions. > > AFAICT, that workaround cannot work on modern Squids because all traffic > subject to ssl_bump rules will start as a (real or fake) CONNECT request. I'm running `Squid Cache: Version 5.0.1-20200312-r8a511d5e0' _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
