librelist archives

Re: [mongrel2] How to determine secure connection from application?

From:

Mathijs Kwik

Date:

2011-06-07 @ 08:36

I believe
X_FORWARDED_PROTO: https
is the most common one.

I've seen this in common nginx setups (http://brainspl.at/nginx.conf.txt)
It's used by node-http-proxy
(https://github.com/nodejitsu/node-http-proxy/blob/master/lib/node-http-proxy.js)
And ruby on rails looks at it to detect ssl.


On Tue, Jun 7, 2011 at 10:15 AM, Sabin Iacob <iacobs@m0n5t3r.info> wrote:
> On 06/07/2011 10:56 AM, Zed A. Shaw wrote:
>> On Tue, Jun 07, 2011 at 12:16:40AM -0700, emax991 wrote:
>>> Hi,
>>>
>>> I just added SSL to my app and it seems to be working fine. However there
>>> doesn't seem to be any way to tell from the application that it is
>>> communicating over a secure connection. Or am I missing something? For
>>> example with other server interfaces I'd check the HTTPS environment
>>> variable.
>> Hmmm, yeah we can add a header.  I'll research what others are doing and
>> either replicate or make something similar.  I doubt we'll try sending
>> client certs though.
>
> I am aware of 2 such conventions used in reverse proxying: one is
> X-Forwarded-SSL: on and the other X-Forwarded-Protocol: ssl[1]; I
> suppose using one of these should be enough :)
>
> [1] although one would expect to have x-forwarded-protocol: https/http
> instead of ssl, it forces you to bend over backwards to set the thing in
> an nginx setup, for instance: https://gist.github.com/1006281
>

On 06/07/2011 11:36 AM, Mathijs Kwik wrote:
> I believe
> X_FORWARDED_PROTO: https
> is the most common one.
>
> I've seen this in common nginx setups (http://brainspl.at/nginx.conf.txt)
> It's used by node-http-proxy
> 
(https://github.com/nodejitsu/node-http-proxy/blob/master/lib/node-http-proxy.js)
> And ruby on rails looks at it to detect ssl.

hmm, so gunicorn is doing it wrong then, because it looks for
x-forwarded-protocol: ssl (at least it obeys x-forwarded-ssl: on, which
I ended up using)

It seems a couple of load balancers use X-Forwarded-Proto: https to signal
ssl

http://www.geekisp.com/faq/6_65_en.html

I haven't read the documentation of mongrel in about 3 months so bear with
me, but if the headers are not already configurable, it could be a good
candidate either as a filter or as an ssl option, that way you can use
X-Forwarded-Proto: https or X-Forwarded-Ssl: on depending on the backend app
and what is expecting as shown in some documentation pages:
http://wiki.apache.org/couchdb/Nginx_As_a_Reverse_Proxy#SSL_with_nginx



On Tue, Jun 7, 2011 at 3:36 AM, Mathijs Kwik <bluescreen303@gmail.com>wrote:

> I believe
> X_FORWARDED_PROTO: https
> is the most common one.
>
> I've seen this in common nginx setups (http://brainspl.at/nginx.conf.txt)
> It's used by node-http-proxy
> (
> https://github.com/nodejitsu/node-http-proxy/blob/master/lib/node-http-proxy.js
> )
> And ruby on rails looks at it to detect ssl.
>
>
> On Tue, Jun 7, 2011 at 10:15 AM, Sabin Iacob <iacobs@m0n5t3r.info> wrote:
> > On 06/07/2011 10:56 AM, Zed A. Shaw wrote:
> >> On Tue, Jun 07, 2011 at 12:16:40AM -0700, emax991 wrote:
> >>> Hi,
> >>>
> >>> I just added SSL to my app and it seems to be working fine. However
> there
> >>> doesn't seem to be any way to tell from the application that it is
> >>> communicating over a secure connection. Or am I missing something? For
> >>> example with other server interfaces I'd check the HTTPS environment
> >>> variable.
> >> Hmmm, yeah we can add a header.  I'll research what others are doing and
> >> either replicate or make something similar.  I doubt we'll try sending
> >> client certs though.
> >
> > I am aware of 2 such conventions used in reverse proxying: one is
> > X-Forwarded-SSL: on and the other X-Forwarded-Protocol: ssl[1]; I
> > suppose using one of these should be enough :)
> >
> > [1] although one would expect to have x-forwarded-protocol: https/http
> > instead of ssl, it forces you to bend over backwards to set the thing in
> > an nginx setup, for instance: https://gist.github.com/1006281
> >
>



-- 
Those who do not understand Unix are condemned to reinvent it, poorly.
Any sufficiently recent Microsoft OS contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of Unix.