217871 - RFE: cache only SSL content

Status: RESOLVED WONTFIX

(Core :: Networking: Cache, enhancement)

Description

[Lewis Jardine]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

It's a pretty common configuration for a network to have many machines behind a
large cache, such as a squid. The centralised cache can cache any content apart
from content encrypted in transit, such as https:// URLs. Behind a centralised
cache of several gibibytes, a client-side cache is pretty redundant.

If it was possible to configure mozilla to only cache encrypted content, there
would be more space in the cache for encrypted content, and it would not be
displaced by unencrypted content that is probably in the central cache anyway.

Such an enhancement would greatly reduce the bandwidth use for graphics-heavy
SSL sites, such as sourceforge.net and paypal.com

Reproducible: Always

Steps to Reproduce:

Comment 1

[Matthias Versen [:Matti]]

Mozilla doesn't use the disc cache for SSL pages. (Security Feature)

Comment 2

[Jo Hermans]

Reporter, we're not (yet) caching SSL-content on disk at all, only in memory.
That's done for security reasons (see bug 75354). Bug 205921 should enable the
caching of SSL-data, for those that wish to do it. See also bug 71448, bug
205914, bug 43938.

I don't think we should keep a cache for SSL, and not for regular data, only
because you have a good and fast cache that doesn't want to keep SSL-data.

Comment 3

[Lewis Jardine]

Correct me if I'm wrong, but the network paradigm of many clients connecting to
the web through one (logical) proxy server is not exactly uncommon. Also, it is
my opinion that this would be a useful thing to do in the memory cache as well
as the disk cache. If security is an issue (does mozilla take steps to ensure
that the memory cache is not swapped to disk?), an option to reserve the memory
cache for SSL would be a start.

Regarding comment 2, it's not that the 'good and fast cache' doesn't want to
keep SSL data, it's that it *can't*. SSL is encrypted, and proxies deal with it
by providing the client with a TCP tunnel. The intermediate cache can't cache
SSL data, because it has no access to the session key (which it only known to
the client and the webserver).

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Lewis Jardine]

I believe this is still an issue: many clients around a central cache is still a
common configuration, and overall performance could still be improved by
reserving the cache for data only the client is capable of caching.

Comment 7

[Massimo B.]

For not missing this issue, here is a copy of my comment on that duplicate bug, after this bug report is writeable again:

I completely agree with Lewis. The whole idea of a small/fast/private cache is implemented in projects like Polipo. However without disabling the FF cache, almost everything is cached twice on the same host (if the proxy is running on localhost). There may be still an advantage of keeping the memory cache of FF if using the proxy's cache which is memory buffered too but behind http/pipelining etc. But it is definitly worth to keep SSL content cache in the client because that is the only location it could be.

Only SSL investigating proxies may be able to cache this content. Therefore I would need to thrust the proxies identity and make it read the content. Most scenarios don't do that and just tunnel the SSL traffic like Lewis said.

Moreover the feature request is simple and easy, not a big design to implement. The requirement exists, no question.

BTW, the sentence "Mozilla doesn't use the disc cache for SSL pages. (Security Feature)" from Matthias is out-dated. Today there is browser.cache.disk_cache_ssl which is true by default.