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

Valentin V. Bartenev vbart at nginx.com
Thu Jan 30 10:44:54 UTC 2014


On Thursday 30 January 2014 10:05:04 Ragnar Rova wrote:
> 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://.

This is indeed very strange.  But if you don't want user to see "http"
in his location bar, why do you use Alternate-Protocol instead of just
redirecting them to https?

This Alternate-Protocol thing is not well defined and was removed from
SPDY specification in draft 3 or above.

  wbr, Valentin V. Bartenev


> 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
> >



More information about the nginx-devel mailing list