On 8/10/2013 4:22 a.m., John Gardner wrote:
This email has been classified as: NOT PROTECTIVELY MARKED
This email has been classified as: PROTECT I wonder if someone can help me out
with an issue that has come to light with a new application we are running
behind our Squid 2.6 Reverse Proxy Server.
Please upgrade. 2.6 is now unable to cope with many web applications
which are starting to assume or require HTTP/1.1 functionality.
At the moment we have a situation shown below;
INTERNET ---> |FIREWALL1| ---> |REVERSE-PROXY| ---> |FIREWALL2| --->
APPLICATION WEB SERVER
For all applications, Traffic comes in on HTTPS (and HTTP as well, but mostly
HTTPS) from the Internet, passes through FIREWALL1 and then offloads the SSL at
the REVERSE-PROXY, then the rest of the traffic flows as HTTP through FIREWALL2
and onto the APPLICATION WEB SERVER.
This works for all of the sites we've been serving for the past two years, but
for this particular new application, if you connect using https://my.server.com
when the app redirects, Squid appears to go to http://my.server.com i.e. it
does not stay encrypted. I've found a similar problem in this post using
mod_proxy
(http://serverfault.com/questions/388927/apache-reverseproxypass-redrects-to-http-rather-than-https)
This is not clear what you are saying the problem is. With properly
configured Squid the proxy->server connection should be passing request
through exactly as the client delivered them so te server apps have full
and correct details to work from.
Are you able to share the squid.conf contents? that will help clarify
what the proxy is actually doing vs what you think it should be doing.
Amos
