4 ms·

Off the top of my head I can think of several ways to compromise on this by making shared caching opt-in. One way is for the requester to specify if the asset

Off the top of my head I can think of several ways to compromise on this by making shared caching opt-in. One way is for the requester to specify if the asset is shared. A new 'shared' attribute on html tags and XMLHttpRequest would do this. Browsers enforce cache isolation _unless_ the shared attribute is set, in which case it comes from a 'shared' cache. So if the attacker requests a www.forum.example/moderators/header.css from the _shared_ cache, but the forum software itself didn't specify it was shared so it never got loaded into the shared cache, then nothing is leaked. And as it would only make sense to opt to share stuff like jquery.js from a CDN, the forum wouldn't naturally share that css file and so on. The other approach is for the response to specify sharing, e.g. new cache control headers. Only the big CDNs would bother to return these new headers, and most programmers wouldn't have to change anything to regain the speedup they just lost from going to isolated caches once the CDNs catch up and return the header. In either case, sharing can _still_ be an information channel if the shared resource is sufficiently rare e.g. the forum admin page is pretty much the only software stuck on version x.y of lib z. The attacker can see if its in the cache, and infer if the victim is a logged-in admin or not. Etc.

wpietri 7y ago
I think the trouble with both of these plans is that it shifts cognitive load to a lot of people who aren't expert in the topic. How many people would put "shared" on something because it sounds good, or is the default in a template? And even if they don't, how many brain-hours do we have to burn on people understanding the complexity of an optimization that probably doesn't make much difference to the average website?
- halfdan 7y ago
  Isn't the bigger problem that the developer then choses for the user whether to leak information or not?
  - domenicd 7y ago
    Yes, precisely this. You can't let web sites "opt in" to tracking users. That's the exact wrong threat model to be using here.
  - willvarfar 7y ago
    If the enemy is the developer then you've already lost. Its not like cache sharing is how a developer chooses to unmask your anonymity when browsing between sites; they have cookies to do that in much better ways. A long time ago PHK wrote some very salient comments about HTTP 2.0 efforts https://varnish-cache.org/docs/trunk/phk/http20.html https://varnish-cache.org/docs/trunk/phk/http20.html https://queue.acm.org/detail.cfm?id=2716278 https://queue.acm.org/detail.cfm?id=2716278 etc. He puts forward the case for a browser-picked client-session-id instead of a server-supplied cookie.
    - Majromax 7y ago
      > If the enemy is the developer then you've already lost. It's not that the developer is the enemy. Pretend I create a website called "Democratic Underground: how to foster democracy under a repressive regime." I'm naive, or I want it to load quickly, or I accidentally include a framework that is either of those two -- some library versions are cached. Now, the EvilGov includes cache-detection scripting on its "pay your taxes here" webpage. Despite my salutatory goals, shared caching leaks to the government some subset of my readers.
- hinkley 7y ago
  I don’t think it does. I think it shifts the load to CDN maintainers. Which is fine because we just gave them a task to do that avoids obsolescence. The browsers have always allowed cross domain requests which have been tolerated until now but involved all of us being aware of XSS and CSRF issues, or suffering the consequences. Removing shared cache is the beginning of the end for cross domain requests by default. The other obvious use these days is ad networks, but they also get used for integrations like SSO and shared services like Apple Pay and presumably PayPal? And other collaborations between companies. But those could also be opt in.
- gregable 7y ago
  What if: a) the origin sharing the resource must place a .well_known/static_resource file in place. b) The presence of .well_known/static_resource prevents any request on this origin to send cookies, and any set-cookie header is ignored. c) The document that includes the resource on this sharing origin must use subresource integrity attributes when loading the shared resource. d) the resource cannot be cached unless the cache-control header is public and has a lifetime of at least 1 hour. This guarantees that the resource is always requested cookieless, and that the resource can't vary per request, otherwise the subresource integrity check would fail.
  - progval 7y ago
    Why .well_known/ instead of HTTP headers (possibly on a HEAD request beforehand, like CORS)?
    - gregable 7y ago
      To ensure the entire origin had the same policy. Perhaps that's unnecessary though.
ndesaulniers 7y ago
Having the server be explicit about an asset being ok to share via cache thwarts the attack described in the link. And thats not too much for the CDNs to enable.

wpietri 7y ago

I think the trouble with both of these plans is that it shifts cognitive load to a lot of people who aren't expert in the topic. How many people would put "shared" on something because it sounds good, or is the default in a template? And even if they don't, how many brain-hours do we have to burn on people understanding the complexity of an optimization that probably doesn't make much difference to the average website?

halfdan 7y ago
Isn't the bigger problem that the developer then choses for the user whether to leak information or not?
- domenicd 7y ago
  Yes, precisely this. You can't let web sites "opt in" to tracking users. That's the exact wrong threat model to be using here.
- willvarfar 7y ago
  If the enemy is the developer then you've already lost. Its not like cache sharing is how a developer chooses to unmask your anonymity when browsing between sites; they have cookies to do that in much better ways. A long time ago PHK wrote some very salient comments about HTTP 2.0 efforts https://varnish-cache.org/docs/trunk/phk/http20.html https://varnish-cache.org/docs/trunk/phk/http20.html https://queue.acm.org/detail.cfm?id=2716278 https://queue.acm.org/detail.cfm?id=2716278 etc. He puts forward the case for a browser-picked client-session-id instead of a server-supplied cookie.
  - Majromax 7y ago
    > If the enemy is the developer then you've already lost. It's not that the developer is the enemy. Pretend I create a website called "Democratic Underground: how to foster democracy under a repressive regime." I'm naive, or I want it to load quickly, or I accidentally include a framework that is either of those two -- some library versions are cached. Now, the EvilGov includes cache-detection scripting on its "pay your taxes here" webpage. Despite my salutatory goals, shared caching leaks to the government some subset of my readers.
hinkley 7y ago
I don’t think it does. I think it shifts the load to CDN maintainers. Which is fine because we just gave them a task to do that avoids obsolescence. The browsers have always allowed cross domain requests which have been tolerated until now but involved all of us being aware of XSS and CSRF issues, or suffering the consequences. Removing shared cache is the beginning of the end for cross domain requests by default. The other obvious use these days is ad networks, but they also get used for integrations like SSO and shared services like Apple Pay and presumably PayPal? And other collaborations between companies. But those could also be opt in.
gregable 7y ago
What if: a) the origin sharing the resource must place a .well_known/static_resource file in place. b) The presence of .well_known/static_resource prevents any request on this origin to send cookies, and any set-cookie header is ignored. c) The document that includes the resource on this sharing origin must use subresource integrity attributes when loading the shared resource. d) the resource cannot be cached unless the cache-control header is public and has a lifetime of at least 1 hour. This guarantees that the resource is always requested cookieless, and that the resource can't vary per request, otherwise the subresource integrity check would fail.
- progval 7y ago
  Why .well_known/ instead of HTTP headers (possibly on a HEAD request beforehand, like CORS)?
  - gregable 7y ago
    To ensure the entire origin had the same policy. Perhaps that's unnecessary though.

ndesaulniers 7y ago

Having the server be explicit about an asset being ok to share via cache thwarts the attack described in the link. And thats not too much for the CDNs to enable.