Visser, Peter (ZGM) wrote:
Hi, I am using Squid as a reverse proxy/SSL gateway. Clients can connect with HTTP and HTTPS. All internal connections to the webserver use HTTP. This way the proxy acts as a SSL off loader. Now an application I use, Roundcube webmail, which has the option of redirecting to HTTPS when using HTTP. But since all connection to webserver all always HTTP the application gets stuck in a loop. Since it will try to redirect and the proxy will undo the redirect.
As you say it's an option, one you need to turn off in order to meet your desire of all squid->server traffic be HTTP-only.
Your Squid has the authoritative info about whether the request was received over HTTP or HTTPS. Let it send the 302/303 redirect as it should be.
I found out that one way to solve this would be to use the x-forwarded-proto field so that the web application can recognize if the client is using SSL or not.
Ah, a custom header. One that makes all sorts of claims about the network security situation. Claims which can't be verified. ie how do you know it was *your* proxy which added it? and which step of a multi-hop path across the Internet was the HTTPS one?
Theres a nice thread in the Tomcat developers discussing what to do about multiple copies, miss-spellings, and the several alternative names being used. Seems they even have real-life cases of whole sequential strings of the header being received by web servers.
And some nginx admin(s) going around blaming Squid for this mess.
Is there a way to get Squid to send this option (besides x-forwarded-for) to the web server? I search on the web but no luck so far.
Squid handles it like all unknown non-standard headers: Pass straight through.
The security implications of allowing this to be trusted are dodgy to say the least.
Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.6 Beta testers wanted for 3.2.0.1
