Re: [squid-users] FW: X_FORWARDED_PROTO Support?

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