Encrypt Network Cache
Categories
(Core :: Networking: Cache, enhancement, P3)
Tracking
()
People
(Reporter: simonf, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged][necko-priority-next])
The network cache contains cookie data so we should encrypt it.
This may be a dupe since we have discussed this in the past but I could not find the other bug.
|
||
Comment 1•1 month ago
|
||
There could be significant performance issues with encrypting/decrypting the cache, which is on a very hot path for cache hits in particular. What would the keying be, such that an attacker who got the encrypted file but for some reason didn't have access to the unlocked machine wouldn't be able to decrypt it?
The problem is that this has to be decrypted without a user-entered key, so presumably the key has to live in the profile itself. It would be odd if the attacker could get the cache files but couldn't get the profile, though it is possible.
Is there a design document for this, or back-of-a-napkin design?
|
Reporter | |
Comment 2•1 month ago
|
||
It will be possible to enable/disable the encryption so if performance is very bad for certain users they can chose to turn it off or not enable it.
The encryption key will be the same that we are going to use for encrypting other databases like cookies. It will be available early during startup. If that is because it is a primary password that the user has to enter or a key that Firefox Enterprise gets from the SSO system or a key stored in an OS key store should be abstracted away from the code that does the actual encryption here.
|
|
||
Comment 3•1 month ago
|
||
Users won't know that encryption is making firefox slow (and/or users will randomly share "turn this setting off to make firefox faster" even when it doesn't for them). We need to make it fast enough that users don't need to turn it off. The best way to deal with this would be as part of a larger redesign/reimplementation, perhaps in rust
|
||
Comment 4•1 month ago
|
||
So for applications that require an encrypted cache we can instead flip the browser.cache.disk.enable pref to false. This avoids the use of a disk storage and uses an in memory HTTP cache, just like we do for private browsing.
To make the current cache compatible with encryption, I think we'll need to wait for the next planned refactoring (cache3) that would have encryption baked in, and would hopefully be multi threaded as to improve performance.
Description
•