Re: HTTP/2.0 -04 candidate

On Tue, 2 Jul 2013, Sam Pullara wrote:

> 
> On Jul 2, 2013, at 10:36 AM, David Morris <dwm@xpasc.com> wrote:
> > 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.
> 
> Browsers associate security with the origin server. If I can serve
> content from an arbitrary origin that is a problem without trust.
> Rewriting the URLs with a different origin solves this problem and thus
> is not an issue.

If the html from server: examplex.com as written references host:
x.example.com, and before delivering it, examplex.com rewrites it to
a url for examplex.com (in the html) and keeps track of the mapping so
that the PUSH_PROMISE knews where to get the content from, and serves
the other server's content, how is that not a bigger problem them
providing a PUSH_PROMISE with the correct identification?

> > 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 would allow one domain on a VPS serve content for any other domain 
> on a VPS.

Exactly what happens with HTTP/1.1 virtual hosts. The TCP connection is
shared to serve data from multiple virtual hosts.

I don't see this as a problem that needs to be prevented. If the
PUSH_PROMISE doesn't make the offer, all that will happen is that
the client will notice the common IP and make the request itself.
All to negate the advantage of the PUSH methodology.

Received on Tuesday, 2 July 2013 19:13:22 UTC