[squid-users] ssl_bump with cache_peer problem: Handshake fail after Client Hello.

Amos Jeffries squid3 at treenet.co.nz
Thu Nov 5 14:07:17 UTC 2015

On 6/11/2015 12:30 a.m., maple wrote:
> Hi Amos,
> So, if I understand it right, it's impossible to do ssl-bump even I use the
> proxychains to chain the squid with my parent proxy without using
> cache_peer(because I'm confirmed that ssl-bump+cache_peer must not work in
> squid), am I right?

No that is not what I said. There are multiple (twelve!) different types
of input traffic involved; a querter of them work in Suqid-3.5, half of
them work in Squid-4, and half still do not work yet.

You need to be using the latest 3.5 release (3.5.11) for bumping to work
properly. And upgrade frequently. TLS interception is an arms race
situation where things change almost monthly or even weekly.

> I just wonder how admin900710 make things work by using squid+proxychains
> since he/she look like claim did it if I understand right.

Start with "What does proxychains deliver to Squid?" that is key to
understanding what needs to be done, and what can be done.

> about your second answer, sorry, I'm not sure I understand it. so I describe
> my environment here again:
> client <---https---> gateway with iptables + squid <---proxychains---> proxy
> mapping port <---ssh tunnel---> http proxy + me <--http/https--> internet
> as you see, client and gateway are all located in internal network, there is
> no NAT device to make int-net to reach http proxy outside, so I setup ssh
> reverse tunnel to map http proxy to int-net(it did like NAT to do port
> mapping, but all traffic built on ssh tunnel).

Two questions:
 are you the sysadmin for that network?
 and why is there a full separation like that?

The first Squid should be configured with a cache_peer. Using an IP:port
that will go through the ssh tunnel to the remote proxy, and also using
the "ssl" option.

To use proxychains in there, it needs to take the TLS connections from
first squid and just deliver them to second squid without wrapping in a

Since the first Squid now knows the peer is using a secure connection
the first Squid should be okay with sending HTTP requests over the
encrypted link to the peer.

The second proxy should have a https_port to receive the traffic. No
special mode flags are needed here. It is just a proxy receiving
requests that happen to contain https:// URLs.

> I can use proxychains to to chain tools like yum/apt or other command line
> tool in int-net with my http proxy, but I need to run automatic script or
> install some complex system in my int-net which sometimes require proxy,
> sometimes not, it's hard to do proxy setting in client side, so transparent
> proxy seems suitable way, so squid is introduced, but it must handle
> https(ssl-bump) and use parent http proxy, how to do it in same time? squid
> apparently not support it, so i want to let squid just play transparent
> proxy role with ssl-bump, and use proxychains to connect it to upstream
> I tried several ways to integrate them, but looks squid just not forward it
> traffic to upstream proxy which proxychains designate, so as I ask above, is
> it possible to let squid forward traffic to other proxy by using 
> proxychains?

Squid cannot take encrypted traffic and generate a CONNECT to send to
another proxy *over plain-text TCP*.

However, if that other proxy is receiving TLS connections (https_port)
then Squid can deliver secured content there without needing any fancy
CONNECT wrappings.

It is only plain-HTTP proxies which have problems.


More information about the squid-users mailing list