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

Re: Security of cross-origin pushed resources

From: Roberto Peon <grmocg@gmail.com>
Date: Sat, 21 Sep 2013 14:31:59 -0700
Message-ID: <CAP+FsNe8mXKRv62vc8Y9YNG_DHyuqKeqSxi=2JEeatUxtShcMA@mail.gmail.com>
To: Jo Liss <joliss42@gmail.com>
Cc: (wrong string) ™ˆ™˜Œ) <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
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


On Sat, Sep 21, 2013 at 2:02 PM, Jo Liss <joliss42@gmail.com> wrote:

> On Fri, Sep 20, 2013 at 9:08 PM, Patrick McManus <pmcmanus@mozilla.com>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
>
> --
> Jo Liss
> http://www.solitr.com/blog/
>
Received on Saturday, 21 September 2013 21:32:27 UTC

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