Re: [squid-users] https could not access with ssl bump in squid 3.4

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 26 Feb 2014 23:00:42 +1300

On 26/02/2014 8:06 p.m., Jerry OELoo wrote:
> Hi Amos:
> Thanks for your quick feedback.
> 1) I do not much understand your said about connect to host
> 10.64.12.100, I just find it in B (10.64.12.101) squid cache.log,
>

It is the reason your ssl-bump is not working. The SSL connection is not
actually going to any relevant web server, but being connected back to
the client IP.

The ORIGINAL_DST indicates that it was the IP address details for server
taken from the TCP packets on the client->server connection which was
intercepted into Squid.

These connections show up as client IP being server if you have one of
these happening:

* Linux TPROXY mechanism used to intercept, but "intercept" flag used on
the port.

* client making explicitly configured (PAC file, environment variable or
browser config settings) connections directly to the proxy port.

> 2) I do not add any other setting in squid.conf about interception.
>

I mean do you have iptables settings using DNAT, REDIRECT or TPROXY
targets to point the port 443 traffic at the Squid https_port ?

> 3) As you mentioned, https_port requires NAT interception, so in my
> scenario, A, B are in the same LAN, and I want to A use B as HTTPS
> proxy, and I want to use SSL bump to monitor A's HTTPS content. so is
> there any way that can meet it?

Yes. What you have shodul be enough for the Squid setup. However
interceptio is done in teh networking layers...

 1) you must first *route* the port 443 packets through the Squid box.

 2) you must TPROXY/DNAT/REDIRECT *intercept* the packets into teh Squid
listenign port.

 3) catch the packets in Squid and ssl-bump.

You have show that you are doing (3). The problem is happening somewhere
at (1) or (2).

Amos
Received on Wed Feb 26 2014 - 10:00:48 MST

This archive was generated by hypermail 2.2.0 : Wed Feb 26 2014 - 12:00:06 MST