W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Security of cross-origin pushed resources

From: 陈智昌 <willchan@chromium.org>
Date: Fri, 20 Sep 2013 20:13:33 -0700
Message-ID: <CAA4WUYhj10L19ExtZhmRy29o6dzDWrCmvv+y84MCC-dPNVxc9Q@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Jo Liss <joliss42@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
I think you're not stating some context. Are you assuming some form of
authentication for http URIs?

On Fri, Sep 20, 2013 at 7:53 PM, Roberto Peon <grmocg@gmail.com> wrote:

> 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.
Received on Saturday, 21 September 2013 03:14:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC