[squid-users] Issues with CMS Redirects and Squid as Reverse Proxy

Amos Jeffries squid3 at treenet.co.nz
Thu Jan 22 04:16:13 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/01/2015 10:41 a.m., John Gardner wrote:
> We have a Squid 3.4 server configured as a Reverse Proxy on Oracle 
> Linux 6.  It is working correctly for most sites, those which are
> HTTP all the way through to the peer, Those which are HTTPS all the
> way through to the peer and those which have SSL offloaded at the
> external interface on Squid.  We have however come across a problem
> when using a proprietary Content Management System.  In this CMS,
> you set each page to show how it should be served i.e. HTTP or
> HTTPS.  If traffic comes into the CMS with HTTP and it's set for
> HTTPS, the CMS tries to re-write/force the URL so that it comes
> back with https:// at the start.
> 
> The problem is that, this appears to come through Squid as an 
> indefinite loop and the page fails.  When connecting a Browser 
> directly to the CMS server, and using the same site and page
> settings, it works, but when going through squid, it doesn't.  Now,
> I'm willing to believe that the CMS is affecting the HTTP traffic
> so that it is not strict and that Squid then fails as it it doesn't
> know how to handle it, but I thought I would post here and see if
> anyone could help.
> 
> Our config is the following (with obfuscation);
> 
> http_port 10.x.x.42:80 accel defaultsite=server_2.bl.co.uk 
> https_port 10.x.x.42:443 accel
> cert=/usr/newrprgate/CertAuth/www/s.crt 
> key=/usr/newrprgate/CertAuth/www/southtynesidehomes_key.pem 
> cipher=ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM 
> options=NO_SSLv2,NO_SSLv3 defaultsite=server_2.bl.co.uk cache_peer
> 10.x.x.202 parent 80 0 no-query originserver name=server_2_http 
> cache_peer 10.x.x.202 parent 443 0 no-query originserver
> login=PASS connection-auth=on ssl 
> sslcert=/usr/newrprgate/CertAuth/www/peer_keys/www.pem
> sslversion=1 sslflags=DONT_VERIFY_PEER front-end-https
> name=server_2_https acl sites_server_2 dstdomain www.s.org.uk 
> cache_peer_access server_2_http allow sites_server_2 
> cache_peer_access server_2_https allow sites_server_2 
> cache_peer_access server_2_http deny all cache_peer_access
> server_2_https deny all

For a backend CMS like that you need to add protocol type to the peer
selection criteria:

 acl HTTPS proto HTTPS

 cache_peer_access server_2_http allow sites_server_2 !HTTPS
 cache_peer_access server_2_http deny all

 cache_peer_access server_2_https allow sites_server_2 HTTPS
 cache_peer_access server_2_https deny all


PS. It is long past time to seriously look at verifying the peer
connection traffic. All you need is to set sslcafile= (or sslcapath=
if there are multiple) with the peer CA cert and drop the sslversion=1
and sslflags=DONT_VERIFY_PEER parameters.


Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUwHmNAAoJELJo5wb/XPRjUFEIAKHLNgt+nceH49NHYVGWFifJ
jXZPihncq76xquM9Qe2rUMnW7TqW1jxNmyrofScx0l1chlm2GX8xYcPh72E0cog8
p0XEBt/D0Q0ydaN5PDa5ouDY2gJVps2lTeLY5/nmciBZbzlMW5tzwiL0fAkyYVSf
MdP8tn2TM1sC8cdMHMZ6aIu79/h9RbqslFlOoqaNa1yrH4PefIp3Csoa28CnrZ2B
WHtQN4eI0zsYvGNEvOI2gWBlK3ygQCf9ks3T9Df3n6MBglldsu44CcA7/zDdXW+G
iSdUXSw17M0gZUTMN1jf77ehf8FGKxBtiqqU1FzO2Yswucuqz4RvxPP32J+ZcEI=
=lA68
-----END PGP SIGNATURE-----


More information about the squid-users mailing list