[squid-users] Best way to prevent squid from bumping CONNECTs
3m9n51s2ewut at thismonkey.com
Thu Apr 30 16:10:30 UTC 2020
> 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
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
> > 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'
More information about the squid-users