Re: Security of cross-origin pushed resources

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