[PATCH] SPDY: set $scheme from scheme request header
Ragnar Rova
rr at mima.x.se
Thu Jan 30 08:07:05 UTC 2014
Maybe its a Chrome bug, but I have seen chrome connecting over ssl/spdy and
setting the scheme: header to "http"
>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;
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140130/0802aa92/attachment-0001.html>
More information about the nginx-devel
mailing list