Re: [squid-users] SQUID / transparent proxying

On 14/05/2013 1:48 a.m., Warner Moore wrote:
>> -----Original Message-----
>> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
>> Sent: Saturday, May 11, 2013 6:01 AM
>> To: squid-users_at_squid-cache.org
>> Subject: Re: [squid-users] SQUID / transparent proxying
>>
>> Really? "seamlessly"? I think you did not have it working at all then.
> Thanks for the response. Perhaps more information will help.
>
>
>> This same exact configuration will work identically in in all squid-2.6+ and
>> squid-3.0+, even the 3.2/3.2 versions. Traffic will be terminated by Squid using
>> the *single* static certificate you configured Squid with.
>> All clients will get a popup on *every* HTTPS site they visit warning about a
>> hijack by your proxy unless you have configured them to trust your self-signing
>> CA.
>> If you see anything different you have either *not* intercepted the traffic like
>> you thought. Or the SSL on your network is fundamentally broken beyond repair.
> The https_ports are configured for the web sites' CN that they are terminating.
>
>
>> Ah, *NAT* is not working on the Squid box. This is unrelated to the HTTPS parts.
>>
>> The NAT operations _must_ be done on the Squid box. Use policy routing
>> to move packets between machines without NAT to get them to the Squid box.
> I have read that. My particular configuration is a bit different...
>
> Squid is terminating SSL for several domains.
>
> www.domain1.com
> www.domain2.com
> foobar.domain1.com
>
> The external facing Internet IPs have a destination NAT on an external facing device. IE:
>
> www.domain1.com -> 1.2.3.4 -> 10.10.0.50
> www.domain2.com -> 1.2.3.5 -> 10.10.0.60
> foobar.domain1.com -> 1.2.3.4 -> 10.10.0.50
>
> Example excerpt SQUID 2.6 configuration:
>
> https_port 10.10.0.50:443 cert=/etc/squid/keys/wildcard.domain1.com.crt key=/etc/squid/keys/wildcard.domain1.key cipher=RC4-MD5:RC4-SHA:AES128-SHA:DES-CBC3-SHA:AES256-SHA options=NO_SSLv2 transparent
> https_port 10.10.0.60:443 cert=/etc/squid/keys/www.domain2.com.crt key=/etc/squid/keys/www.domain2.key cipher=RC4-MD5:RC4-SHA:AES128-SHA:DES-CBC3-SHA:AES256-SHA options=NO_SSLv2 transparent
> url_rewrite_host_header off
> url_rewrite_program /etc/squid/redirector-https.pl
> acl TheOriginServer dstdomain www.domain1.com
> acl TheOriginServer dstdomain www.domain2.com
> acl TheOriginServer dstdomain foobar.domain1.com
> http_access allow TheOriginServer
> http_access deny all
>
> Hosts file pointing to internal load balancer IPs:
>
> 10.10.0.150 www.domain1.com
> 10.10.0.150 foobar.domain1.com
> 10.10.0.160 www.domain2.com
>
> Works great. Provides client termination, URI re-writes, and caching of static content. I have been unable to successfully configure Squid 3.3 in a similar fashion. I have been using the new intercept with ssl-bump on the https_port and ssl_bump client-first TheOriginServer. I have tried several different things unsuccessfully. Do you have any thoughts how I can maintain this configuration with Squid 3.3?

With 3.3 you should expect to be seeing lots of warnings about Host
forgery, possibly also NAT failures, etc. and caching of all this
traffic will be disabled by the security systems to protect against
those failures. Each a sign that all is not well inside Squid. NP: These
breakages were happening all along, but not displayed by versions 3.1
and older.

Are these domains that you own? if so then you should be using a
reverse-proxy configuration for them with the domain DNS pointing at
your public IP(s). And this same change also applies to all the Squid
versions back as far as 2.6.

These changes can be done to make the above setup a reverse-proxy:
  * on your https_port lines swap "transparent" for "accel".
  * create a cache_peer line for each of the load balancer IPs, with
"originserver" flag. This replaces the /etc/hosts hacks.
  * use cache_peer_domain or cache_peer_access to filter which traffic
goes to each cache_peer / loadbalancer IP.

PS. you can probably drop the re-writer as well but that depends on what
exactly it does. Leave that to last.

Amos
Received on Mon May 13 2013 - 15:11:55 MDT