[squid-users] Non-transparent proxy with cache_peer and ssl_bump

Amos Jeffries squid3 at treenet.co.nz
Thu Mar 21 03:22:21 UTC 2019


On 21/03/19 10:58 am, Alex Rousskov wrote:
> On 3/20/19 3:23 PM, Yosi Greenfield wrote:
> 
>> ssl_bump splice step3 NoBump
>> ssl_bump bump step3
> 
>> cache_peer proxy2.ourserver.com ... ssl
> 
> Forwarding most SslBump-related connections to cache_peers is still
> unsupported by official Squids, including Squid v3 and v4. Measurement
> Factory code that implements this feature is being officially reviewed
> at https://github.com/squid-cache/squid/pull/380/
> 
> If you can test the above-referenced code, please do.
> 
> However, even if the above-referenced changes are officially accepted
> (into v5), they will not allow you to do "TLS inside TLS" -- you will
> not be able to forward most SslBump-related connections to HTTPS proxies
> (i.e. your "cache_peer ssl").
> 
> Fortunately, forwarding to HTTPS proxies is not critical in most use
> cases -- one layer of TLS encryption is often enough. Unfortunately, you
> will expose CONNECT requests between Squid1 and Squid2 until we add that
> support or perhaps [controversially] allow bumped traffic to be sent to
> HTTPS proxies without additional encryption. I am not aware of anybody
> working on either right now.
> 


Er, sending the bumped https:// requests to a cache_peer with 'ssl' does
work, though not advised. It is equivalent to the client-first type
SSL-Bumping which has a lot of nasty security side effects.


What is broken here is that squid2 config has http_port receiving the
TLS connections from squid1. So when the plain-text response arrives
from squid2 instead of a TLS server handshake squid1 produces that
negotiate error.



Yosi:

The quick-fix is to add an https_port line to you squid2 and make the
squid1 cache_peer line point at that port instead of 3130.
 Be aware the cert= parameter on squid2 https_port will be used by
squid1 to bump *all* traffic you send through that cache_peer link -
thus causing those nasty client-first problems.

OR, to avoid the client-first effects do not use cache_peer at all. Let
the squid1 traffic go 'direct' and use interception to divert that port
443 traffic into squid2. YMMV on whether this works.

OR, use the experimental PR code Alex referenced for your squid1 and
remove the 'ssl' options from the cache_peer.



Also, please remove DONT_VERIFY_PEER. It hides important problems from
*you* while sill letting them cause major issues to clients. It is not
even useful for debugging because of that hiding.

Also, "sslproxy_cert_error allow all" is a similarly bad idea. There are
*some* errors which you may need to allow, but not everything. Use this
directive with great care. Look into every error that shows up. Properly
fix as many as you can first. Only after that hide the ones which are
still necessary to ignore.


Amos


More information about the squid-users mailing list