Re: [SRI] To trust or not to trust a CDN

The reason for non-canonical-src in a minimum viable product, and for it
to not check integrity, is the widespread presence of "authorized" proxies
that modify content, especially script content.  These are deployed at a
significant number of networks in enterprises, governments and the
military. I expect that resource authors might be willing to let the 1-2%
of users behind such appliances suffer poor performance after SRI
deployment, in order to increase safety for everyone else.  But I doubt
they are willing to outright break those users.

It's the same reason that key-pinning has an "out" for trust roots that
aren't pre-installed.  That approach seems like a better solution,
functionally, (disable SRI if you got a valid HTTPS connection chaining to
a non-pre-installed trust anchor) but I worry that it is a layering
violation.

-Brad

On 11/19/14, 4:44 PM, "Brian Smith" <brian@briansmith.org> wrote:

>On Sat, Nov 8, 2014 at 8:20 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
>wrote:
>>> Do you have a pointer to an explanation about why it is important for
>>> SRI to not be part of CSP?
>>
>> I don't think SRI should not be part of CSP; I just don't think it
>> should be part of CSP exclusively. I don't think anyone has written
>> down any reasoning , but let me try list some reasons that I thought
>> of right now :)
>
>Last week, I met with Devdatta and he made a good point regarding CSP:
>Although the spec doesn't say so, most people expect that CSP will
>block a request from ever being made. But, in order to verify a digest
>for SRI enforcement, the browser has to make the request and verify
>the result. For this reason, it doesn't seem to make sense for SRI to
>be part of the CSP source list directive. Do other people agree with
>this reasoning? I think it makes sense.
>
>> With stuff like non-canonical-src, there is some security relevant
>> sensitive inline with the page still. For example, if the CDN server
>> is haxored and there is XSS on the host page, then the CDN server
>> could be told return malicious files, the hash (from CSP) won't match
>> and the browser will host stuff from non-canonical-src (provided by
>> attacker) which again means we are pwned.
>
>It would be very surprising to me for SRI to be defined in such a way
>that the non-canonical-src wasn't also subject to the SRI restrictions
>in the same way src is, so I don't understand what the problem is.
>
>Also, it isn't clear to me that noncanonical-src is necessary for a
>minimal viable product SRI 1.0. I don't see the motivation for it in
>the use cases in the current editor's draft. Why not defer it to v2?
>
>The point was also raised that SRI is kind of more fundamental than
>CSP, because a properly-functioning website (no XSS vulnerabilities)
>should not need to use CSP at all (at least the source list
>directives), but a properly-functioning website still benefits a lot
>from SRI. So, I agree that it doesn't make sense to block SRI on
>improving its integration with CSP.
>
>The most important use case for SRI is making CDNs safer to use, to
>help with HTTPS deployment. This is a use case that shouldn't have to
>wait for Service Workers. With this in mind, I am surprised that the
>current editor's draft cut out support for stylesheets but kept
>noncanonical-src for v1. Arguably, it is even more important for
>performance to deliver stylesheets from an untrustworthy-but-fast
>server than it is to deliver scripts, and the safety concerns are not
>too different.
>
>Cheers,
>Brian
>

Received on Thursday, 20 November 2014 01:24:41 UTC