Re: Security of cross-origin pushed resources

+1


On Sat, Sep 21, 2013 at 1:18 PM, Roberto Peon <grmocg@gmail.com> wrote:

> This looks good to me, or at least is the right direction.
> -=R
>
>
> On Sat, Sep 21, 2013 at 8:42 AM, Patrick McManus <pmcmanus@mozilla.com>wrote:
>
>> 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.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>