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

Hey Mark!

On Mon, Nov 3, 2014 at 7:25 PM, Mark Watson <watsonm@netflix.com> wrote:

> I understand that HTTP is no longer considered eligible for SRI, for good
> reasons [1]. Also that the ability of SRI / HTTP resources to escape
> mixed-content blocking is not something which had been agreed.
>

I think it's fair to say that there's strong opposition to weakening the
promise that user agent's UI makes to users. TLS should provide both
integrity and privacy; it's not clear how we could continue to make that
guarantee if portions of a page could load over HTTP.

It's equally unclear how we could distinguish between an XHR that loaded
data a site would programmatically act upon, and an XHR used to load video
data. XHR is multipurpose in a way that <video> and <audio> aren't; the
latter would be a safer starting point for experimentation.


> Second, requiring HTTPS doesn't really solve the Verizon identifier
> attack, or similar: such an identifier could still be associated with the
> TLS connection, for example in a TCP option, some extension to the initial
> TLS exchange or even a totally independent message sent to the destination
> identifying the TLS connection by its IP 5-tuple.
>

TLS would prevent _Verizon_ from injecting such an identifier into the TLS
stream, though. You're correct, of course, that Verizon's privileged
position allows it to play side-channel tricks with IP address assignment
(IPv6 will make that sort of thing easier).


> But, anyway, is there anything that could be done in terms of request
> integrity with HTTP ? Thinking aloud, could the response be required to
> include an HMAC of the request, using a key provided to the UA by the site
> ? That does not prevent destination server and network colluding, but does
> prevent modification of requests sent to non-colluding sites.
>

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 would expect that response headers be not visible to JS on the XHR, to
> avoid the attacks where networks attach unique identifiers to responses.
>

Well, that's a problem: one of SRI's requirements has been that
integrity-checked resources be delivered with CORS headers that enable JS
access as part of a mechanism to ensure that the contents of non-public
resources aren't brute-forcable via integrity checks (see
http://w3c.github.io/webappsec/specs/subresourceintegrity/#is-resource-eligible-for-integrity-validation
for detail).

I'm not sure that restriction is conducive to Netflix's use case.


> Another line of thought would be whether TLS could be used for HTTP sites ?
>

I guess you're referring to opportunistic encryption? Firefox seems to have
bought into the concept, but you won't be shocked to hear that many of the
same people you're already talking to on the Chrome team about TLS aren't
particularly enthused about those proposals. :)

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)