Intent to Implement- Double-keyed HTTP cache

[Sebastian Streich]

Intent to Implement- Double-keyed HTTP cache


Summary:

Currently Browsers are vulnerable to cache-timing attacks, commonly
referred to as XS Leaks attacks. Starting with Firefox 70 we want to
explore a double-keyed HTTP cache. Instead of solely using the origin of
the resource, we will double key the HTTP Cache using the top-level origin.
Using the top-level origin as the 2nd Key in the HTTP Cache allows to
counterfeit XS Leaks and eliminates the ability of checking cache contents
across Origins.

Bug: Bugzilla 1536058
<https://bugzilla.mozilla.org/show_bug.cgi?id=1536058>

Standard: https://github.com/whatwg/fetch/issues/904

Platform coverage: all platforms

Estimated or target release: Firefox 70

Preference: The feature will be pref'd behind
“browser.cache.cache_isolation”

and disabled by default.

Other browsers:

webkit: shipped

Chrome <https://bugs.chromium.org/p/chromium/issues/detail?id=910708>:
implementing

web-platform-tests: <none yet>

Secure contexts: This feature isn’t restricted to Secure Contexts.
Estimated or target release: Firefox 70

[Martin Thomson]

Hi Sebastian,

I'm glad to see us moving toward having better isolation in this way.

In discussions of this sort of keying strategy, the guidance I repeatedly
hear is that "double-keying" isn't sufficient and that you need to key on
the chain of origins. That is, if A frames B and C, and B in turn also
frames C, then the two C frames are isolated from each other in the same
way that they are isolated from a top-level C.

I took a look at both the fetch issue and your patch and it wasn't clear
what strategy we're using. As an aside, an issue on a repo isn't really a
specification. I couldn't find a PR on fetch either.

What is the tuple we're keying on?

Cheers,
Martin

On Thu, Aug 22, 2019 at 3:40 AM Sebastian Streich <sstr...@mozilla.com>
wrote:

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Anne van Kesteren]

On Thu, Aug 22, 2019 at 4:26 AM Martin Thomson <m...@mozilla.com> wrote:
> What is the tuple we're keying on?

Top-level origin only. This still allows C to attack B in your
scenario (or vice versa). There's a variety of other side channel
attacks on "<iframe> sites" too, including various members of the
Window object, history.length, and clickjacking. It would also allow B
or C to attack A, though there's a number of other things possible
there too.

I definitely think it's worth figuring out how we can enable "<iframe>
sites" to better protect themselves as well as figuring out how to
improve sandboxing of "<iframe> sites", but it would require a broader
effort than caches I think. I think isolating by top-level origin is a
huge improvement over the status quo and stops a fair number of
practical attacks against major sites (modulo popup attacks, see
Cross-Origin-Opener-Policy for that). (Many of which you can't frame
to be clear, due to X-Frame-Options.)

[d...@chromium.org]

On Thursday, August 22, 2019 at 11:26:55 AM UTC+9, Martin Thomson wrote:
> Hi Sebastian,
>
> I'm glad to see us moving toward having better isolation in this way.
>
> In discussions of this sort of keying strategy, the guidance I repeatedly
> hear is that "double-keying" isn't sufficient and that you need to key on
> the chain of origins. That is, if A frames B and C, and B in turn also
> frames C, then the two C frames are isolated from each other in the same
> way that they are isolated from a top-level C.
>
> I took a look at both the fetch issue and your patch and it wasn't clear
> what strategy we're using. As an aside, an issue on a repo isn't really a
> specification. I couldn't find a PR on fetch either.

For what its worth, browsers are also discussing what changes will need to be made for certain requests (like prefetch) in a double-keyed world. See [1], and the associated HTML Standard PR [2]. But you're right, there doesn't seem to be a real spec change at the moment for double-keyed cache itself from what I know.

]1]: https://github.com/w3c/resource-hints/issues/82
[2]: https://github.com/whatwg/html/pull/4115

[Anne van Kesteren]

On Wed, Aug 21, 2019 at 7:40 PM Sebastian Streich <sstr...@mozilla.com> wrote:
> Estimated or target release: Firefox 70

The plan is to enable this on Firefox 72 Nightly to see if there's any
fallout that needs addressing. It will not ride the trains. This is
tracked by https://bugzilla.mozilla.org/show_bug.cgi?id=1594004.

As network caches in general are a privacy and security concern, we're
tracking isolating all of them using the top-level origin in
https://bugzilla.mozilla.org/show_bug.cgi?id=1590107. If there are
further caches that could use such isolation, please do file a bug
blocking that bug.