Re: Security of cross-origin pushed resources

Wait a sec, that isn't what I'm saying..

I'm saying, regardless of scheme, that no element should be interpreted as
a result of a push for an origin unless that origin has been authenticated.
Of course, there are other requirements for HTTPS about authentication,
which make this statement less interesting for HTTPS, but it is interesting
for HTTP...

-=R


On Fri, Sep 20, 2013 at 5:59 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> All very convincing points. I'm supportive of changing the spec to remove
> cross-origin push for http URIs.
>
>
> On Fri, Sep 20, 2013 at 1:08 PM, Patrick McManus <pmcmanus@mozilla.com>wrote:
>
>> I think Jo has a reasonable point. Cross origin pushes that can have
>> their domain be backed up by a verifiable cert are pretty awesome, but
>> lacking that we shouldn't allow them in an unverified context.
>>
>> no matter what we do in specification land, people are going to put L4
>> load balancers in front of two nodes that aren't really related to each
>> other (an issue the cert can sort out) and this becomes a pretty easy
>> exploit. We would essentially be changing the definition of origin from
>> hostname to be resolved-ip and I don't think that's in our purview to do.
>>
>>
>> On Fri, Sep 20, 2013 at 3:26 PM, William Chan (陈智昌) <
>> willchan@chromium.org> wrote:
>>
>>> I think this is a good question that I don't know is well specified
>>> anywhere. I recall us discussing for HTTP/1.1 whether or not it's feasible
>>> for a client to reuse a TCP connection for the same destination IP address,
>>> even if it's for different origins. My understanding is mnot ran a quick
>>> test of the feasibility and showed that it works 99.X% of the time or
>>> something, but my memory's vague on the matter. Mark can correct me here.
>>>
>>>
>> I've done the research on this in the past - but the details are fuzzy.
>> There was a prominent LB that had a switch through mode that was a
>> recommended performance best practice.. basically after finding the first
>> request (cookies and host header primarily) it determined what back end to
>> use and from there just went into a TCP tunnel thereafter. So there were
>> definite security issues and interop argument along the lines of "it works
>> for N nines" probably isn't enough.
>>
>
>