Subject: Security of cross-origin pushed resources

From: Jo Liss <[email-masked]>
Date: Fri, 20 Sep 2013 19:55:12 +0100

[Originally at https://github.com/http2/http2-spec/issues/248]

Hey all,

http://http2.github.io/http2-spec/#rfc.section.10.1 says:

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

I worry whether this might be insecure: For instance,
`foo.herokuapp.com` and `bar.herokuapp.com` could conceivably live
behind a load balancer at the same IP address, yet `foo` shouldn't be
able to push resources for `bar`. (Or am I mis-reading the spec here?)

I'm guessing the expectation would be: If the load balancer speaks
HTTP 2.0, it would forward individual streams to the servers, so we
can expect it to enforce that servers don't send unauthorized push
promises.

But what if an HTTP 1.1 load balancer forwards the entire TCP
connection once it sees a Host: field? Then the server could
conceivably upgrade to HTTP 2.0 and push resources that it isn't
allowed to push.

Could this happen? What do you think?

Cheers,
Jo

-- 
Jo Liss
http://www.solitr.com/blog/

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 20 Sep 2013 12:26:49 -0700

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.

If it's reasonable to reuse a TCP connection for the same IP address but
for different origins, and we specify this in httpbis (I don't know what
httpbis has to say about this), then I think the current draft HTTP/2 spec
is fine. And I think it's desirable to support this, especially if you have
a CDN which services many origins off the same VIP. Of course, it's a
little tricky at the client, because if you receive a push promise from a
different origin, then you have to do a DNS lookup before you can tell if
you can accept it.

---

From: Jo Liss <[email-masked]>
Date: Fri, 20 Sep 2013 20:35:42 +0100

On Fri, Sep 20, 2013 at 8:26 PM, William Chan (陈智昌)
<[email-masked]> wrote:
> 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

Hm, it might work most of the time, but I imagine it would be unsafe
and browsers wouldn't actually do this. Or am I completely mistaken
here?

Jo

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 20 Sep 2013 12:41:40 -0700

> and browsers wouldn't actually do this. Or am I completely mistaken

Speaking as a browser vendor, this idea has come up a number of times.
We've definitely looked at doing it. It's a lot of work because of how we
do our connection management, and it has unclear performance benefits
(although it's probably a win), and most importantly it's not clear how
safe it is. Oftentimes we'd run an experiment for things like this to see
if it breaks anything in the wild, but the code development and maintenance
costs have been prohibitive.

---

From: Patrick McManus <[email-masked]>
Date: Fri, 20 Sep 2013 16:08:07 -0400

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.

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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 20 Sep 2013 15:56:16 -0700

imho, cross-origin push should only be allowed when the cert has
authenticated the endpoint as being authoritative for the other entity.
-=R

On Fri, Sep 20, 2013 at 1:08 PM, Patrick McManus <[email-masked]>wrote:

> 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 (陈智昌) <[email-masked]
> > wrote:
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 20 Sep 2013 17:59:32 -0700

All very convincing points. I'm supportive of changing the spec to remove
cross-origin push for http URIs.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 20 Sep 2013 19:53:11 -0700

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 (陈智昌)
<[email-masked]>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.
>>
>> On Fri, Sep 20, 2013 at 3:26 PM, William Chan (陈智昌) <
>> [email-masked]> wrote:
>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 20 Sep 2013 20:13:33 -0700

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 <[email-masked]> wrote:

> On Fri, Sep 20, 2013 at 5:59 PM, William Chan (陈智昌) <[email-masked]
> > wrote:
>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 20 Sep 2013 20:46:59 -0700

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 (陈智昌)
<[email-masked]>wrote:

>> 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.
>> On Fri, Sep 20, 2013 at 5:59 PM, William Chan (陈智昌) <
>>> All very convincing points. I'm supportive of changing the spec to
>>> remove cross-origin push for http URIs.
>>>
>>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 20 Sep 2013 21:21:10 -0700

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 <[email-masked]> 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 (陈智昌) <[email-masked]
> > wrote:
>
>>>>> 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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 20 Sep 2013 22:36:25 -0700

On Sep 20, 2013, at 9:21 PM, William Chan (陈智昌) 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?
> 
> 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.

Umm, I hope folks realize that this last sentence forbids any
form of hierarchical caching.

....Roy

---

From: Glen Knowles <[email-masked]>
Date: Sat, 21 Sep 2013 00:53:10 -0700

We've developed several servers internally that, in addition to their main
job, operate as HTTP servers for monitoring and control. Since our
framework operates by duping and handing off sockets to processes based on
the type of service requested the HTTP support was implemented in the same
way, routing the socket to a process based on the host header. So if
requests to other vhosts are sent over the same socket they will arrive at
a process that has no way to deal with it.

I arrived at this model because 1) it was easy, 2) I could find no RFC that
addressed it, and 3) all the browser that I tested worked this way.

So there are at least some servers in the wild :)

As a counter example ARR (the Windows based load balancer bundled with IIS)
does multiplex requests of different hosts that resolved to the same
IP+port over shared TCP connections.

On Fri, Sep 20, 2013 at 10:36 PM, Roy T. Fielding <[email-masked]> wrote:

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

---

From: Eliot Lear <[email-masked]>
Date: Sat, 21 Sep 2013 15:37:53 +0200

Roy,

On 9/21/13 7:36 AM, Roy T. Fielding wrote:
>
>>
>> A client MUST NOT use, in any way, resources provided by a server
>> that is not authoritative for those resources.
>

Are you saying that a proxy is a server or an LB isn't authoritative?

Eliot

---

From: Patrick McManus <[email-masked]>
Date: Sat, 21 Sep 2013 08:42:18 -0700

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.

On Fri, Sep 20, 2013 at 9:21 PM, William Chan (陈智昌)
<[email-masked]>wrote:

>> On Fri, Sep 20, 2013 at 8:13 PM, William Chan (陈智昌) <
>>>>> On Fri, Sep 20, 2013 at 1:08 PM, Patrick McManus <[email-masked]
>>>>> > wrote:
>>>>>
>>>>>> 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

---

From: Roberto Peon <[email-masked]>
Date: Sat, 21 Sep 2013 13:18:02 -0700

This looks good to me, or at least is the right direction.
-=R

On Sat, Sep 21, 2013 at 8:42 AM, Patrick McManus <[email-masked]>wrote:

> 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>,
> On Fri, Sep 20, 2013 at 9:21 PM, William Chan (陈智昌) <[email-masked]
> > wrote:
>
>> cross-origin push for http URIs." I meant http:// scheme, and primarily
>> I meant unauthenticated (I know that Patrick is hopeful we can authenticate
>>>>> 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 1:08 PM, Patrick McManus <
>>>>>> [email-masked]> wrote:
>>>>>>

---

From: Jo Liss <[email-masked]>
Date: Sat, 21 Sep 2013 22:02:23 +0100

On Fri, Sep 20, 2013 at 9:08 PM, Patrick McManus <[email-masked]>wrote:

> Cross origin pushes that can have their domain be backed up by a
> verifiable cert are pretty awesome

I don't understand TSL (and how it's going to work with HTTP 2.0) very
well, but at least for HTTP 1.1, the cert doesn't seem to be an indication
of authorization.

For instance, Heroku's HTTP 1.1 load balancer terminates the SSL and
presents a certificate for *.herokuapp.com.
https://better-tweet-feed.herokuapp.com/ has a *.herokuapp.com cert, but
the actual HTTP server backing it is controlled by yours truly, and I'm
definitely not authorized to push resources for other subdomains under
herokuapp.com.

So I guess if we want to rely on the cert for cross-origin pushes, we have
to be sure that this kind of thing can't happen for HTTP 2.0. Can we
actually be sure about that?

Sorry to be a pain in the butt!

Jo

---

From: Roberto Peon <[email-masked]>
Date: Sat, 21 Sep 2013 14:31:59 -0700

Remember that in cases such as you're describing, there is, functionally, a
reverse proxy here which has the role of delegating authority within the
trust domain.
Nothing can prevent it from failing at that purpose if that is how it is
implemented.

If there is a wildcard cert, it should be given only to entities that are
reasonably responsible for all domains under that cert.
Even today, with HTTP/1.1 the situation you present could be problematic if
people do first-request-only based steering for a connection, and traffic
is passing through a coalescing proxy.

-=R

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 21 Sep 2013 14:45:58 -0700

+1

On Sat, Sep 21, 2013 at 1:18 PM, Roberto Peon <[email-masked]> wrote:

>> On Fri, Sep 20, 2013 at 9:21 PM, William Chan (陈智昌) <
>>> 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 7:53 PM, Roberto Peon <[email-masked]>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
>>>>>>>>> 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