Re: [squid-users] Transparent proxy

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 06 Apr 2011 23:38:14 +1200

On 06/04/11 20:28, Paweł Mojski wrote:
> Hi Guys;
>
> I'm new one on the list so at the beginning I'd like to say hello to all
> regular readers :)
> I'm using squid (3.1.1 at this moment) in huge service and I'm wondering
> about one think.
>
>>
>>> c) Can squid proxy SSL requests transparently ?
>>>
>>
>> Yes. But only for one definition of "transparent": the HTTP RFC
>> definition.
>> /pedant
>>
>> It will not handle NAT intercepted SSL.
>
> I have something like this in my squid.conf file:
>
> pl-waw1 ~ # grep transparent /etc/squid/squid.conf
> http_port 10.1.1.1:8080 transparent
> https_port 10.1.1.1:8443 transparent sslBump cert=/etc/squid/cert.pem
>
> And it works very fine with DNAT redirection.
>
> Also, please anyone explain me what is the difference in deprecated
> sslBump and new one ssl-bump.

Just bug fixes. The "sslBump" in config was a typo. It was supposed to
be ssl-bump from the start.

> I tried to upgrade squid, but to new sslbumping format was not working
> fine.
> How should I use it?

On "http_port" without the "transparent".

The ssl-bump feature takes the details from CONNECT headers and uses
them to create a certificate for the destination server (by name!) to
decrypt the SSL traffic inside the tunnel.

It does not work on https_port due to the missing name and is ignored in
older configs.

What does sometimes work there (and seems to have been for you) is the
NAT interception (aka old "transparent" flag) *if* the client browser
foolishly accepts Squids https_port certificate stating an obviously
wrong domain name.

The recent Squid releases are being a bit more strict about what they
allow. But to match that "-k parse" and the WARNING level of cache.log
is also being more informative about config changes and how to resolve them.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.6
Received on Wed Apr 06 2011 - 11:38:19 MDT

This archive was generated by hypermail 2.2.0 : Wed Apr 06 2011 - 12:00:03 MDT