Re: [squid-users] SQUID / transparent proxying
On 14/05/2013 1:48 a.m., Warner Moore wrote: -Original Message- From: Amos Jeffries [mailto:squ...@treenet.co.nz] Sent: Saturday, May 11, 2013 6:01 AM To: squid-users@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
RE: [squid-users] SQUID / transparent proxying
> -Original Message- > From: Amos Jeffries [mailto:squ...@treenet.co.nz] > Sent: Saturday, May 11, 2013 6:01 AM > To: squid-users@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.
Re: [squid-users] SQUID / transparent proxying
On 11/05/2013 11:35 a.m., Warner Moore wrote: I've been using SQUID for years to terminate inbound client connections to externally facing web sites. With SQUID 2.6, I specified transparent in the https_port, setup some acls, and it worked seamlessly. Really? "seamlessly"? I think you did not have it working at all then. 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. I have been trying to get a similar configuration working with SQUID 3.3. Changing the 'transparent' to intercept, adding ssl-bump, and then setting ssl_bump client-first to the appropriate domains. Unfortunately, I'm receiving these errors: 2013/05/10 18:33:11 kid1| NF getsockopt(SO_ORIGINAL_DST) failed on local=192.168.123.123:443 remote=4.4.4.4:11034 FD 12 flags=33: (92) Protocol not available Ah, *NAT* is not working on the Squid box. This is unrelated to the HTTPS parts. Will this configuration still work with modern SQUID or must a different approach be taken? I appreciate any help, this is starting to frustrate me. 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. Amos
[squid-users] SQUID / transparent proxying
I've been using SQUID for years to terminate inbound client connections to externally facing web sites. With SQUID 2.6, I specified transparent in the https_port, setup some acls, and it worked seamlessly. I have been trying to get a similar configuration working with SQUID 3.3. Changing the 'transparent' to intercept, adding ssl-bump, and then setting ssl_bump client-first to the appropriate domains. Unfortunately, I'm receiving these errors: 2013/05/10 18:33:11 kid1| NF getsockopt(SO_ORIGINAL_DST) failed on local=192.168.123.123:443 remote=4.4.4.4:11034 FD 12 flags=33: (92) Protocol not available Will this configuration still work with modern SQUID or must a different approach be taken? I appreciate any help, this is starting to frustrate me. 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.
