Re: [SRI] Escaping mixed-content blocking for video distribution

On Wed, Nov 12, 2014 at 6:15 PM, Brian Smith <brian@briansmith.org> wrote:

> On Wed, Nov 12, 2014 at 2:50 PM, Mark Watson <watsonm@netflix.com> wrote:
> > Yes. If this is a big concern, then it would be a reason to consider the
> > video-specific option I outlined in my earlier mail.
> >
> > However, what is the concern with respect to passing the XHR bytes to
> > Javascript ?
>
> I think the concerns about mixed content, in general, are described
> well at http://www.w3.org/TR/mixed-content/#intro and
> http://www.w3.org/TR/mixed-content/#categories.
>
> >  If this is a security concern, isn't this mitigated by the
> > requirement for the script to provide a hash of the response ?
> Presumably,
> > if the script has a hash of the response, then it could probably obtain
> the
> > actual response some other way (indeed, it could request it over HTTPS).
> So,
> > we're not giving any bytes to Javascript that it couldn't get anyway.
>
> We can very easily demonstrate this reasoning is faulty with a
> counterexample. Here is a SHA-256 hash of some content:
> a3d6b8110635bb9726fddaab6a638f13fc8bf68227f5de4763e25273571e354e.
> Please post the content that was hashed.
>

​This is not what I meant, obviously.

The authentication and integrity aspects of ​
http://www.w3.org/TR/mixed-content/#intro are addressed by the provision of
the hash by the script running in an authenticated origin. It is
vanishingly unlikely that the script has possession of a hash and that data
arrives in the XHR matching that hash, but the data is not the data the
script expects.

To be even clearer, let's compare the properties of the case where the
script issues the request (providing an SRI hash) over http and the case
where it issues the same request, with the same SRI hash, over https. There
is no difference from a security perspective. The same data is exposed to
Javascript in both cases. There is a difference from a privacy perspective,
of course, first because both the request and response are in the clear in
the HTTP case and second because attacks like the Verizon one are simpler
with HTTP.

Unless you are worried about attackers who have the ability to create hash
collisions. Such an attacker could indeed replace the resource in flight
with a different one that has the same hash. Is this the concern ?


> We're trying to eventually disable all mixed content so that browsers'
> security indicators are simple enough to be truly meaningful to
> end-users. I think a lot of security and privacy engineers would admit
> that the actual security and privacy issues regarding HTTP vs HTTPS
> are more nuanced than all-or-nothing, but it seems like all-or-nothing
> is all we can expect end-users to understand, so that forces us into
> all-or-nothing approaches.
>

​Fair enough, but what I'm trying to ask here is whether the addition of
request integrity as well as SRI gets us close enough to the HTTPS case​
that the security indications are meaningful ? I think the request
integrity idea mitigates the second privacy issue above, so we are back to
the first privacy issue alone. How does that square with the alternative of
sites remaining entirely HTTP for considerably longer ?

If the answer is that it would be better to wait longer for full HTTPS in
the case of XHR, is the answer the same if we find a way to restrict the
integrity-protected mixed content to audio/video ?

...Mark



>
> Cheers,
> Brian
>