On 14/05/2013 1:48 a.m., Warner Moore wrote:
-----Original Message-----
From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx]
Sent: Saturday, May 11, 2013 6:01 AM
To: squid-users@xxxxxxxxxxxxxxx
Subject: Re: 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
