Re: HTTP/2.0 -04 candidate

On Tue, 2 Jul 2013, Sam Pullara wrote:

> On Jul 2, 2013, at 10:05 AM, William Chan (???) <willchan@chromium.org> wrote:
> > From 
> > http://www.techradar.com/us/news/internet/how-the-amazon-silk-browser-works-1036102:
> > """ Another interesting trick: Silk keeps track of this parsing.
> > Jenkins says Silk can keep track of how the processing worked for,
> > say, the last 100,000 users - that in all cases, the same logo header
> > was downloaded and that the page did not change this routine. When you
> > visit using the browser, Silk might decide to use a "smart push" and
> > send you that logo header to speed up browsing even further. """
> > 
> > As far as trust, a browser will trust an explicitly configured forward
> > proxy for http:// resources. For https://, we will tunnel through with
> > CONNECT and do SSL to the origin over the tunnel.
> 
> Got my forward and reverse proxy confused. Makes sense for HTTP with a
> trusted forward proxy ? however, that doesn't mean that every HTTP
> connection should be able to send HTTP resources for any URL. This seems
> like it should be limited to trusted forward proxies and only over HTTP.

Reverse proxies are invisible to the client. Any trust issue is the same
whether one connection or multiple connections are used when traffic
ends up at the reverse proxy.

There is a fundamental flaw in the orgin server security, if you can
trust the server to deliver the original resource but can't trust it
to deliver any pushed content referenced by that page. After all, if
the server owner wants to break trust, it can just rewrite all the
URLs in the base resource to refrence itself and then proxy the
content which isn't local.

If we feel there is a security requirement here, it should be along
the lines of:

  The host name specified in a PUSH_PROMISE must have a DNS entry
  which includes the IP address of server sending the PUSH_PROMISE.

This doesn't apply to visible proxies.

Received on Tuesday, 2 July 2013 17:36:47 UTC