701597 - no-store cache entries should be stored *encrypted* on disk

Status: NEW

(Core :: Networking: Cache, enhancement, P5)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ This bug was initially created as a clone of Bug #413947 +++

This is an idea for being able to store no-store HTTP resources in the HTTP disk cache safely. This would allow us to avoid using the memory cache at all on mobile. The encryption/decryption overhead should be minimal.

1. Every time we are run, generate an encryption key that lives only in memory.
2. Encrypt the cache key using that key when doing writes/reads to/from the cache.
3. Before writing the cache entries to disk, encrypt everything (including the headers, the body, and all the metadata derived from the URL, headers, and body) with the encryption key. Before reading, decrypt.
4. Purge the encrypted entries on shutdown, and purge entries encrypted by previous sessions on startup.

Some operating systems (Windows, and maybe Mac OS X) have APIs for doing per-session encryption like this. Alternatively, we can do this using just NSS.

Comment 1

[Jason Duell]

> This would allow us to avoid using the memory cache at all on mobile.

I don't understand the point of this.  The memory cache is much faster than disk, and that shows up more on mobile than desktop.  Right now I think our problem is that we don't use the memory cache *enough* on mobile (we go straight to disk for anything expect no-store IIRC), and we should implement some sort of "go to RAM first, and when evicted store it on disk" strategy (aka bug 602611).   If that's true (and Nick & co are in a better place to give out the perf stats to determine this), then it's not worth putting the effort into supporting no-cache encrypted on disk AFAICT.

In the interim we might be able to get away with making the memory cache quite small (to avoid the stale entry problem mentioned in bug 413947 comment 8).

I'm restoring the dependency on bug 413947, because it still seems to me that the only reason for doing this would be to preserve no-cache entries when we flush the memory cache on mobile.  And it would probably be worth doing some telemetry to see what % of entries would actually get lost w/o this fix, and how expensive it would be to refetch them (vs fetch off disk and decrypt).  Seems likely to be an edge case that's not worth the extra software work/complexity?

Comment 2

[Justin Lebar (not reading bugmail)]

Do we have any idea how big the necko memory cache can get on mobile?  This would help us triage the bug for memshrink.

On my desktop, it's only 750kb, but maybe I'm not on enough secure sites.  Maybe we should add telemetry for this, if we don't already have it?

Comment 3

[Jason Duell]

The max size for the memory cache for mobile is controlled by browser.cache.memory.capacity, currently set to 1 MB:

 http://mxr.mozilla.org/mozilla-central/source/mobile/app/mobile.js#99

> Maybe we should add telemetry for this, if we don't already have it?

bug 699409

Comment 4

[Jason Duell]

Whoops, I was wrong about the bug # (that was disk cache).  Added bug 702438.

Comment 5

[(dormant account)]

Why store things encrypted on disk? we should write them out, mmap and unlink() the file. This will let os the delete the file when we quit and let it swap it out under memory pressure.

Comment 6

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

sec triage, no action

Comment 7

[Jesse Ruderman]

Would these cache entries be used only for "pinned" uses, such as View Source and Save As?  (I assume they can't be revalidated with web sites.)  Can we destroy the key for a cache entry as soon as the cache entry is no longer pinned?

Comment 8

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

sec traige, still waiting for action on this one

Comment 9

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

still waiting

Comment 10

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258