RE: [squid-users] SQUID / transparent proxying

From: Warner Moore <wmoore_at_2co.com>
Date: Mon, 13 May 2013 13:48:52 +0000

> -----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?

Please pardon the confidentiality notice message.

Thanks,

Warner

CONFIDENTIALITY STATEMENT: All information included in this Communication, including attachment(s), is intended solely for delivery and authorized use by the intended recipient(s), and may contained privileged, confidential, proprietary and/or trade secret information entitled to protection and/or exempt from disclosure under applicable law. If you are not the intended recipient, please note that any use, distribution or copying of this Communication is unauthorized and may be unlawful. If you have received this Communication in error, please notify the sender and delete this Communication from your computer.
Received on Mon May 13 2013 - 13:49:08 MDT

This archive was generated by hypermail 2.2.0 : Mon May 13 2013 - 12:00:05 MDT