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