Re: Security of cross-origin pushed resources

maybe less is more in this case?


10.1 <http://http2.github.io/http2-spec/#rfc.section.10.1> Server Authority
and Same-Origin

This specification uses the same-origin policy
([RFC6454]<http://http2.github.io/http2-spec/#RFC6454>,
Section 3 <http://tools.ietf.org/html/rfc6454#section-3>) to determine
whether an origin server is authorized to provide content.

The resource origin SHOULD be considered to match the server if the
connection can authenticate the domain part of the resource origin with a
TLS certificate used on that connection. Connections to origin servers
without TLS authentication MUST use a single origin.

A client MUST NOT use, in any way, resources provided by a server that is
not authoritative for those resources.





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

> As usual, I feel like when you and I disagree on mailing lists, we spend
> many roundtrips just to find out that we misunderstood each other and we
> actually agree :)
>
> So, when I said "I'm supportive of changing the spec to remove
> cross-origin push for http URIs." I meant http:// scheme, and primarily I
> meant unauthenticated (I know that Patrick is hopeful we can authenticate
> and encrypt http:// URIs in the future, but when I say http:// scheme
> today, I mean unauthenticated). So no cert or anything.
>
> Does that clear it up? If not, then I think I don't understand or just
> actually disagree :P Do you think we need to change the existing text, and
> if so, what do you propose?
>
> http://http2.github.io/http2-spec/#rfc.section.10.1
> =====
> A server that is contacted using TLS is authenticated based on the
> certificate that it offers in the TLS handshake (see [RFC2818], Section 3).
> A server is considered authoritative for an "https" resource if it has been
> successfully authenticated for the domain part of the origin of the
> resource that it is providing.
>
> A server is considered authoritative for an "http" resource if the
> connection is established to a resolved IP address for the domain in the
> origin of the resource.
>
> A client MUST NOT use, in any way, resources provided by a server that is
> not authoritative for those resources.
> =====
>
>
> On Fri, Sep 20, 2013 at 8:46 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
>> No, the domain is authenticated, as per the cert. HTTP-level
>> authentication is different.
>> -=R
>>
>>
>> On Fri, Sep 20, 2013 at 8:13 PM, William Chan (陈智昌) <
>> willchan@chromium.org> wrote:
>>
>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>