[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