[PATCH] SPDY: set $scheme from scheme request header

Ragnar Rova rr at mima.x.se
Thu Jan 30 09:05:04 UTC 2014


Sorry for the confusion regarding scheme value and actual connection method
used. In my above example chrome is using a SSL connection to port 443 to
fetch /foo/a.html, (verified using tcpdump), but the location field shows
http://.
Den 30 jan 2014 09:57 skrev "Igor Sysoev" <igor at sysoev.ru>:

> On Jan 30, 2014, at 12:07 , Ragnar Rova wrote:
>
> Maybe its a Chrome bug, but I have seen chrome connecting over ssl/spdy
> and setting the scheme: header to "http"
>
>
> This is not bug, you can start Chrome with "--spdy=no-ssl" or probably
> "--use-spdy=no-ssl" command line option and
> then Chrome will request spdy over plain socket but as far as I know this
> is experimental feature.
>
> --
> Igor Sysoev
> http://nginx.com
>
> From the users point of view it is not visible that a ssl connection was
> used (no padlock icon etc), so I wanted a redirect to the https:// url
> (mainly to show to the user that it is https)
>
> Using this to reproduce:
>
> server {
>        listen 1.2.3.4:80 <http://1.2.3.4/>;
>
>       location /foo {
>           return 301 https://mysite.com$request_uri;
>       }
>
>      location / {
>          add_header        Alternate-Protocol  443:npn-spdy/2;
>
>          ...
>
>      }
> }
>
> server {
>        listen 1.2.3.4:443 ssl spdy;
>
>       location /foo {
>            alias "/tmp/foo";
>       }
> }
>
> 1. Empty browser cache
> 2. Visit http://mysite.com so that chrome learns of the
> alternate-protocol and will make next connection using spdy
> 3. Now go to http://mysite.com/foo/a.html
>
> Expected https:// in the location field. (Of course, the connection is
> over ssl/spdy port 443 when fetching /foo/a.html). Tested using Chrome
> 32.0.1700.102
>
> I was testing also using spdylay (https://github.com/tatsuhiro-t/spdylay)
> where I can request with "http" scheme by using a url on the form
> http://mysite.com:443/foo/a.html.
>
>
>
> On Thu, Jan 30, 2014 at 7:48 AM, Igor Sysoev <igor at sysoev.ru> wrote:
>
>> On Jan 30, 2014, at 3:18 , Ragnar Rova wrote:
>>
>> Was a bit too quick with example, meant the 443 server does not have such
>> a rewrite, that would mean a loop.
>>
>> server {
>>        listen 1.2.3.4:443 ssl spdy;
>>
>>       location / {
>>                # this location is reachable using a http:// url when
>> using spdy. If so, we want a redirect to the https:// url. How?
>>        }
>> }
>>
>>
>> server {
>>    listen 1.2.3.4:443 ssl spdy;
>>
>>    location / {
>>        error_page  497  =301  https://mysite.com$request_uri;
>>        ...
>>    }
>>
>> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#errors
>> http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page
>>
>> As to "http://" URLs over SPDY, this is impossible now since no browser
>> support this.
>>
>>
>> --
>> Igor Sysoev
>> http://nginx.com
>>
>>
>> On Thu, Jan 30, 2014 at 12:16 AM, Ragnar Rova <rr at mima.x.se> wrote:
>>
>>> Sorry, my mistake, I was introducing a vulnerability by this.
>>>
>>> So, without the patch, how do I setup the redirect from http to https
>>> urls when a http url was visited over spdy/tls?
>>>
>>> I have
>>>
>>> server {
>>>        listen 1.2.3.4:80 <http://1.2.3.4/>;
>>>
>>>        location ~ ^/(path1|path2)$ {
>>>                 rewrite  ^/(.*)$  https://mysite.com/$1  permanent;
>>>                 break;
>>>        }
>>>
>>>        location / {
>>>                 add_header        Alternate-Protocol  443:npn-spdy/2;
>>>        }
>>>  }
>>>
>>> server {
>>>        listen 1.2.3.4:443 ssl spdy;
>>>
>>>        location ~ ^/(path1|path2)$ {
>>>                 rewrite  ^/(.*)$  https://mysite.com/$1  permanent;
>>>                 break;
>>>        }
>>>
>>>       location / {
>>>                # this location is reachable using a http:// url when
>>> using spdy. If so, we want a redirect to the https:// url. How?
>>>        }
>>> }
>>>
>>>
>>> On Wed, Jan 29, 2014 at 11:36 PM, Valentin V. Bartenev <vbart at nginx.com>wrote:
>>>
>>>> On Wednesday 29 January 2014 23:06:40 Ragnar Rova wrote:
>>>> > # HG changeset patch
>>>> > # User Ragnar Rova <ragnar.rova at gmail.com>
>>>> > # Date 1391033075 -3600
>>>> > #      Wed Jan 29 23:04:35 2014 +0100
>>>> > # Node ID 6654eae26c8b2a718e5ad116650faf37f7be7aa9
>>>> > # Parent  01e2a5bcdd8f65f4f7bcb23ac35911da08e5945f
>>>> > SPDY: set $scheme from scheme request header.
>>>> >
>>>> > $scheme variable is always "https" when using spdy, existing code
>>>> > just sets scheme to https based on if we are on a ssl connection.
>>>>
>>>> Yes, and it is intentionally.
>>>>
>>>> > In spdy, there is a scheme header which should be used.
>>>>
>>>> There is nothing special about spdy, the scheme also can be passed using
>>>> request line in plain http or https, and nginx ignores it too.
>>>>
>>>> > Chrome uses http:// urls when establishing connections to sites
>>>> using the
>>>> > Alternate-Protocol header. If you want some locations to be visible
>>>> > to the user as https, you can use $scheme in a http to https
>>>> > redirect rule.
>>>>
>>>> You can use it without this change.  But the patch converts $scheme from
>>>> a configuration restricted variable into an untrusted one (which can
>>>> contain
>>>> arbitrary value sent by client).
>>>>
>>>>   wbr, Valentin V. Bartenev
>>>>
>>>> _______________________________________________
>>>> nginx-devel mailing list
>>>> nginx-devel at nginx.org
>>>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>>>
>>>
>>>
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>
>>
>>
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
>
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140130/bdde0e84/attachment-0001.html>


More information about the nginx-devel mailing list