Re: SRI for preemptive cache validation

On Tue, May 19, 2015 at 1:15 AM, Brian Smith <brian@briansmith.org> wrote:
>
> With HTTP/2's push mechanism, in the same origin case, the server can
> preemptively give the client the new cache validators (ETags, etc) of
> subresources of "/" before the client asks for them, if same-origin. And,
> AFAICT, ths can be done with fewer bytes on the wire than would be required
> for SRI or SRI-like mechanisms. In particular, note that the SHA-2 hashes
> used in SRI are not compressible with deflate (or any algorithm) and cannot
> be truncated, but such restrictions don't apply to cache validators like
> ETags. This can be automated by the web server.
>

Yes, for the same origin HTTP/2 case I think pushing 304s could do
what we need here. Just to confirm, if a server pushes:

    resource: /example.js
    status: 304 Not Modified
    etag: foo

and the browser has /example.js in cache with ETag 'foo', then if the
browser would otherwise have made an "if not modified" request with
ETag "foo" it instead treats it as already validated?

> For other third-party resources (including fonts), it seems you can get a
> lot of the benefit of what you're proposing by having the site hosting the
> third-party subresource make good use of stale-while-revalidate, if/when it
> is implemented by clients. This also seems like something that can be
> implemented with very little manual intervention.

If it's safe for an on-by-default automated system to switch
cache-control headers to stale-while-revalidate, then it would make
more sense for browsers to switch to that being their default
behavior.  It's too dangerous for browsers to make that switch, so
it's also too dangerous for a fully automated system to do it.

>> * Can we make it safe to apply cross-origin, ideally without checking for
>> CORS?
>
> Basically the only way the subresource-hosting server can even attempt to
> mitigate cache timing attacks against the HTTP cache is by carefully using
> HTTP cache control directives on the sensitive resources. If an embedding
> website could instruct the browser to ignore the server's caching directives
> without the server opting into such behavior (e.g. with CORS), then the
> embedding website would be able to thwart such mitigations. Thus, I don't
> see how one would create a safe way of bypassing CORS for such things.
>

This makes sense, thanks!

Jeff

Received on Tuesday, 19 May 2015 13:29:06 UTC