RE: [CSP] "sri" source expression to enforce SRI

I don’t know if this has already been talked about, but maybe long headers
like CSP can be could be put in a well-known resource. It would cost another
roundtrip but save bandwidth in the end  because the resource would be
cached. The CSP header would only need to contain a hash of the resource to
confirm



-----Original Message-----
From: Nottingham, Mark [mailto:mnotting@akamai.com] 
Sent: 05 January 2016 01:59
To: Chris Palmer <palmer@google.com>
Cc: Jonathan Kingston <jonathan@jooped.co.uk>; Brad Hill
<hillbrad@gmail.com>; Joel Weinberger <jww@chromium.org>; Richard Barnes
<rbarnes@mozilla.com>; Patrick Toomey <patrick.toomey@github.com>; WebAppSec
WG <public-webappsec@w3.org>
Subject: Re: [CSP] "sri" source expression to enforce SRI

Catching up after holidays -- I've been wanting to talk about this.

In HTTP/2, the default of SETTINGS_HEADER_TABLE_SIZE is 4k.

>From what I've seen, Chrome and Firefox both stick with the default. 

While 4k of header compression context can help performance considerably,
it's important to understand that HPACK's compression scheme is
coarse-grained, so when the encoder is faced with a large header, it has to
choose between putting it into the dynamic table -- thereby denying use of
that space to other headers -- or repeatedly putting it out onto the wire.

For example, Twitter's response headers already get close to this limit,
mostly thanks to CSP:
https://redbot.org/?id=w5yLyD

Their server has to choose between putting that ~3K CSP header into the
dynamic table, leaving them only about 1k to play with for other headers per
connection, or leave it out, and send it verbatim on EVERY response. They'll
get small benefit from static Huffman coding (which reduces the numbers
above a bit), but that's it.

If a single header value exceeds SETTINGS_HEADER_TABLE_SIZE, it can't be
encoded by reference, and the sender has no choice but to emit it on every
message.

Things get even nastier if there are several large versions of CSP on a
single connection.

Clients could start advertising a larger SETTINGS_HEADER_TABLE_SIZE, but
that means a larger state commitment (both client-side and server-side,
where it can hurt a lot more, offers more DoS exposure, etc.). 

Given that we're already seeing popular sites brush up against this, PLEASE
don't assume that HTTP/2 == free compression, and that we can continue to
merrily add headers. 

Also - when a header is both large and monolithic like CSP (i.e., it doesn't
allow multiple values to be combined into a comma-separated value), it makes
it much harder to optimise for compression, because of HPACK's granularity
(again). I realise that there are security motivations behind this for CSP,
but I wonder if the cost is justified (because once somebody can append
headers, there's a lot of other damage they can do).

Cheers,


> On 23 Dec 2015, at 1:38 pm, Chris Palmer <palmer@google.com> wrote:
> 
> HTTP/2 should do a lot to address header bloat, just as it addresses other
performance problems.
> 
> And, as usual, import content_layer_heaviest from stdarg. :)
> 
> On Tue, Dec 22, 2015 at 6:13 PM, Jonathan Kingston <jonathan@jooped.co.uk>
wrote:
> Perhaps the bloat is something that actually needs to be addressed?
Creating many headers doesn't really solve the bloat issue.
> I agree that it doesn't need to be the core CSP spec especially as we have
UI Security separate etc.
> But yes when we discussed this last certainly one directive isn't flexible
enough for example when SRI expands to images having all assets on the page
requiring SRI would probably be too inflexible.
> 
> On Tue, Dec 22, 2015 at 7:40 PM Brad Hill <hillbrad@gmail.com> wrote:
> I'm open to either possibility. In the past we've talked about things like
fallback policy (e.g. if CDN content from untrusted host X fails the hash
check, try to load from a trusted canonical https source, host Y) that would
be tricky to shoehorn into the CSP directive parsing logic, and policy
combination is another area where it is good not to overcomplicate CSP.
> 
> On Tue, Dec 22, 2015 at 11:29 AM Joel Weinberger <jww@chromium.org> wrote:
> FWIW, I think either approach is fine. I know that, in general, we've been
concerned about CSP bloat, so for that reason alone it might be worth moving
it to its own header. But I don't really care at all either way.
> 
> On Tue, Dec 22, 2015 at 2:28 PM Richard Barnes <rbarnes@mozilla.com>
wrote:
> I'm not sure I agree with that, Brad :)  CSP is where we place
restrictions on loading things, and "must have SRI" is a restriction on
loading things.
> 
> On Tue, Dec 22, 2015 at 2:26 PM, Brad Hill <hillbrad@gmail.com> wrote:
> Yeah, we'd discussed a SRI policy header / meta tag to express a number of
things like this, it just got dropped from v1 to get it out the door.  Not
sure shoehorning it into CSP is the right choice, especially since the
reporting mechanism is already being factored out into its own, reusable,
feature.  Might be simpler to define a standalone header.
> 
> On Tue, Dec 22, 2015 at 11:24 AM Richard Barnes <rbarnes@mozilla.com>
wrote:
> Some sort of "must-sri" directive is something we had considered inside
Mozilla for some of our properties, so this does seem like a productive
thing to look at.  I don't have any personal biases about how exactly to
express it.
> 
> 
> On Tue, Dec 22, 2015 at 12:07 PM, Patrick Toomey
<patrick.toomey@github.com> wrote:
> Yeah, a separate directive probably makes sense. I was originally thinking
it fit into the "locations that are safe" pattern since we are stating that
a location is only safe if it has a known hash (using SRI) from that
location. But, I realize that is a stretch. And, you have a good point about
being able to put other SRI related things in if we have a separate
directive. So, yeah, that is probably the cleaner way to go. Thanks for
opening the tracking issue. 
> On Tue, Dec 22, 2015 at 9:32 AM Joel Weinberger <jww@chromium.org> wrote:
> That's a good point about SRI in general; it's hard to know if you've
forgotten to SRI anything. I'm not sure source-expression is the right place
to put it in CSP, though, as that's meant to be "locations that are safe,"
and that's not exactly what you're requesting. It probably makes sense to
have an 'sri-options' directive, though, since we'll probably want SRI
'report-only' eventually anyway.
> 
> I've filed this as a feature request in GitHub, too:
https://github.com/w3c/webappsec-subresource-integrity/issues/23
> --Joel
> 
> 
> On Tue, Dec 22, 2015 at 2:50 AM Patrick Toomey <patrick.toomey@github.com>
wrote:
> We recently deployed subresource integrity across GitHub.com:
https://github.com/blog/2058-github-implements-subresource-integrity.
However, a few days after deployment we determined that one of our JS
scripts did not have an "integrity" attribute assigned to it. It was our
intent to add the integrity attribute to all subresources on GitHub.com. We
statically vendor in all CSS/JS and use Sprockets (SRI support was added in
https://github.com/sstephenson/sprockets/pull/645) to package these assets
for production deployments. There happened to be one JS file that had not
been vendored, and hence was not being packaged by Sprockets. This violated
two of our goals:
> 
> * Not allowing any dynamically sourced JS (we vendor everything to ensure
what is in version control is what is used in production)
> * Enforcing SRI on all supported subresources on GitHub.com
> 
> Reflecting back on this situation, it would have been nice to have support
in CSP for a source expression such as
"sri"/"sri-only"/"sri-naming-things-is-hard" to ensure SRI is being used
everywhere. In the above scenario, the related JS would have failed to load
and we would have identified both of the issues listed above in testing. 
> 
> 
> 

--
Mark Nottingham    mnot@akamai.com   https://www.mnot.net/

Received on Tuesday, 5 January 2016 11:30:29 UTC