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

On 27/02/2014 8:11 p.m., Jerry OELoo wrote:
> Hi Amos:
> After reading your comments, Below are my questions in detail, Thanks a lot.
> 1) Squid SSL Bump must use in NAT network? as my environment, A and B
> in the same LAN, Can B use Squid SSL Bump to capture all A's https
> traffic?

ssl-bump and NAT have nothing to do with each other. Very separate
mechanisms.

 NAT is *one* way to get the packets to Squid.

 ssl-bump is what gets done with packet payloads IF they happen to be a
SSL/TLS encrypted stream.

> 2) As mentioned in original mail, PC A and PC B are in same LAN, there
> is no NAT network, and PC B (installed squid) which only has 1 network
> interface eth0, As you suggested, I checked iptables, however, I do
> not know how to redirect port 443 traffic to 3130 port as PC A and PC
> B is not NAT.

iptables is what does NAT on PC B. So you can do NAT there for just IPv4
traffic. Or use TPROXY for both IPv4 and IPv4 traffic (without the IP
spoofing part).

Solution involving NAT only on PC B:

a) whatever router PC A uses to reach the Internet does "packet routing".
 - It must pass the port 443 packets from PC A over to PC B exactly as
if PC B was another router on the packets way to the Internet.

b) PC B has NAT setup to pass port 443 packets to Squid.

c) Squid has ssl-bump setup to decrypt the traffic.

d) Squid / PC B contacts the Internet for fetching whatever is allowed.

e) IMPORTANT: PC B packets must be allowed through the router without
step (a) being done on them.

Does that explain better?

Some Extra Notes:

* If the router gateway for the LAN is a Cisco or similar router with
WCCP support it should be able to use WCCP to send the packets to Squid
instead of "packet routing" in step (a) above.

* You can replace step (a) and (b) using an explicit proxy configuration;
  - proxy IP:port in the PC A browser, or
  - PAC file configured in PC A browser, or
  - WPAD protocol with a PAC file.

* You can replace step (b) with basic TPROXY settings.
  In your specific case use Squid-3.4 with "spoof_client_ip deny all" if
you do that.

Amos

>
> On Wed, Feb 26, 2014 at 6:00 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>> 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 Thu Feb 27 2014 - 10:00:45 MST