Re: HTTP/2.0 -04 candidate

On Jul 2, 2013, at 12:12 PM, David Morris <dwm@xpasc.com> wrote:
>> 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?

Because the browser gives it the security constraints of examplex.com and not x.example.com.

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

Many DNS servers only ship a subset of the IP addresses at a time, especially if there are lots of them.

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

In 1.1 I believe that you have separate connection per host name. Also, just because I am hosted on a VPS with hostname sam.vps.com doesn't mean I should be allowed to serve content as if it came from dave.vps.com. This may work for trusted forward proxies, but doesn't work in general.

Sam

Received on Tuesday, 2 July 2013 19:40:28 UTC