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

On Mon, Nov 3, 2014 at 12:06 PM, Adam Langley <agl@google.com> wrote:

> On Mon, Nov 3, 2014 at 11:42 AM, Mike West <mkwst@google.com> wrote:
> > agl@ proposed a Merkle tree approach for streaming data. I think there
> was
> > agreement that that was a reasonable approach, but no one has proposed a
> > delivery mechanism for the digest data that seemed like a good solution.
> > According to Twitter, Freddy's been looking into this recently, so maybe
> he
> > has some good ideas? :)
>
> I think Mark was suggesting that an HTTP *response* include an HMAC of
> the received request in order to detect modification of the request.

​
Yes​.


> I
> don't think that using a Merkle tree for streaming data is related
> here. (Although, if you wanted to deliver the digest data, I'd expect
> it to be interspersed with the content at points convenient for the
> UA.)
>

​I assumed the script was going to provide the hashes, since the content
would be coming over HTTP.


>
> In response to Mark's suggestion as I understand it: (I'm assuming
> that the client includes an nonce in the request otherwise lots of
> obvious attacks are possible.)
>
> This would break whenever any headers were added, removed or altered.
> Sadly, that's not uncommon in the realm of HTTP I believe. Certainly
> there have been cases where "firewalls" removed advertised support for
> gzip encoding in requests because they couldn't scan compressed
> responses. I imagine there's lots more situations like that.
>

Yes. The UA could revert to HTTPS if the check failed, though. I appreciate
that by this time there has already been some leakage of information, just
because of the fact that you tried HTTP.

The prize, if this could be somehow be made to work, is significant, since
it would dramatically reduce the cost for content providers to migrate to
HTTPS for their sites, if not for the actual video data. They would thus be
more likely to do it and sooner. The costs are roughly proportional to
traffic, so if a small fraction needs to be fully HTTPS to get past proxies
etc. then the idea may still be viable.

...Mark





>
> I strongly suspect that such a design would be undeployable.
>
>
> Cheers
>
> AGL
>