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