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

[Scott]

> Date: Mon, 27 Apr 2020 15:09:03 -0400
> From: Alex Rousskov <rousskov at measurement-factory.com>
> To: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] 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'