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

On Mon, Nov 3, 2014 at 11:42 AM, Mike West <mkwst@google.com> wrote:

> 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).
>

​I was thinking that when the attacking network sees a TLS establishment
they just send a separate message to the colluding destination site that
says "The TLS connection with 5-tuple ( ... ) comes from the user with
identity X​." No need to mess with address assignment. As long as there are
no NATs on the path to the colluding site this would work.


>
>
>> 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? :)
>

​My suggestion is that it would be the responsibility of the
(authenticated) site to deliver the hash to the UA ​as with SRI.


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

​I was referring to the response as Adam pointed out. I'll send a separate
response to his points.​


>
>
>> 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. :)
>

​Not opportunistic encryption as implemented by Firefox specifically, but
the general idea of using TLS to obtain some but perhaps not all of the
security privacy benefits of a fully HTTPS site, without representing
​anything to the user.

So, a site operating in this mode might be allowed to use SRI to load HTTP
resources but would otherwise behave just like an authenticated origin.
(The primary objection to using SRI to escape mixed content being that it
still doesn't provide the security and privacy benefits users expect when
they see the green padlock. So, don't show them the padlock.)

​...Mark​



>
> --
> 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.)
>