User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 Build Identifier: This bug is being filed in my capacity as a developer on one of Oracle's largest DHTML projects. Out of the box, Firefox will not cache any HTTPS content on disk, regardless of the headers the server sends. This is problematic for enterprise web apps, which may have a large amount of Javascript, icons, etc. associated with the UI. Despite these data being non-confidential, Firefox users are forced to re-download them upon every login. Internet Explorer obeys headers, caching HTTPS content when the server allows it. As a result, login performance on our app is substantially faster on IE (a pity since once running it's generally faster in Firefox). Because of IE's behavior, the vast majority of servers should already be sending appropriate no-store headers for confidential material. IMHO, we should treat servers that do not do this as a tech evangelism issue. Therefore, we'd like to see the default setting for browser.cache.disk_cache_ssl flipped to true in future versions of Firefox, to permit caching of HTTPS content. Reproducible: Always Steps to Reproduce:

See bug 205921 comment 19

I'm in favor of this change provided we only cache to disk items that have a non-zero freshness lifetime. For example, if a response includes "Cache-control: no-cache", then we should not put it in the disk cache. I think the same is true of responses that have no cache information (e.g., not even a Last-Modified header). It is probably too late to make this change for Firefox 1.5, but one could hope ;-)

if we do this, we should consider offering UI for the pref to disable such caching.

not going to happen for firefox 1.5

Note that if you currently set browser.cache.disk_cache_ssl to true, and go surfing on bugzilla.mozilla.org (which uses https), you'll see the stroked icon in the location bar and the info claims that the content is partially encrypted. Without disk caching it's high-grade encryption. It's probably caused by the images which are now cached. If we'll change the default, we'll also need to fix this, or we'll need to explain this later.

It's caused by the fact that we do not have a way to serialize the security info. Right now, it is just expressed as an object that we can store in memory -- which we do when caching SSL content in the memory cache -- but we have no way to serialize it to the disk cache.

Is there a bug on that issue yet? (I can file one if need be). We should make this bug depend on it. FYI, I'm planning to do a bit of research to gauge whether many major SSL sites are sending stupid caching headers. My guess is virtually none do, since they'd already be in trouble on IE, but it's always good to know...

I don't think we are going to have a good way to serialize SSL security info anytime soon. If someone wants to volunteer a patch, I'd be willing to help review. -> default owner

It appears that current FF versions have this set to true, but the other bug (the broken lock and partially encrypted message) was not fixed. The result is that anybody with a secure shopping cart site is now going to lose sales due to spurious encryption warnings to any visitors using the current FF. Since that is just about every (intelligently-built) site in the world, I'd say that this bug should be considered VERY high priority. Even sites that use the no-cache directive are effected since this apparently still ignores that. This is a serious problem!

(In reply to comment #9) > It appears that current FF versions have this set to true That's incorrect. The pref's default value hasn't changed, it's still false.

Strange, because when somebody in the forums pointed me to it and told me that it was true by default, I looked it up and it was set to true even though I had not heard of it before and thus couldn't have changed it. And I've been getting calls from customers complaining about our lack of security for some time now, so they have it set to true also even though most of them are not technically inclined enough to have changed it.

Are you sure it wasn't changed some other way? Perhaps by some kind of "performance enhancing" extension? Anyways, I'm not sure what "lack of security" means, so if you think there's an issue with Firefox and your site, you'd be better off filing a new bug about it with steps to reproduce. It's not clear that your issues have anything to do with this bug.

No, my issues are directly attributable to this bug. When a visitor has this set to true, they get the broken lock icon and clicking it informs them (incorrectly) that there is unencrypted data on the page. Naturally, they trust that and believe that the page is not secure. Sometimes they call and ask why we don't have a secure page, at which point I can explain the bug in their browser and invite them to try it with IE or Netscape which lets them see that it is perfectly secure. More often than not, they won't bother to call and a sale is lost. And it isn't just my site - this Bugzilla site has the same problem, as does any other secure site. And that is why it's a big issue. And if some performance-enhancement I've installed along the line is what turned it one, then other users can and get the same enhancement so this problem will grow over time until it is fixed. I know the problem is the complications involved in serializing the data, but a quicker workaround would be to make it so the pragma no-cache is respected and tell website owners to use it on any encrypted pages.

Marshall, your problem sounds like bug 262116. I agree that Firefox's default shouldn't change until bug 262116 is fixed. I suggest complaining to the author of the extension that changed your pref, saying the extension shouldn't set the pref as long as it breaks the lock icon.

I agree. I've done some research in the last hour or so and found that setting this to true is actually a very common performance "tip". So it's not an extension, but a step being followed by more and more people. As time goes on, the problem will grow worse as more people become FF users and become sophisticated enough with it to seek out optimization tips. This config option really needs to at least respect the pragma no-cache directive.

Or we should remove the option until it works correctly.

Amen.

Someone should probably file a separate bug on that.

now that bug 345181 has been fixed, Cache-Control: public content is stored on disk. the pref still exists and, if enabled, also stores other SSL content on disk (except cache-control: no-store content, of course).

(In reply to comment #19) > now that bug 345181 has been fixed, Cache-Control: public content is stored on > disk. the pref still exists and, if enabled, also stores other SSL content on > disk (except cache-control: no-store content, of course). > So should we close this bug?

(In reply to comment #20) > (In reply to comment #19) > > now that bug 345181 has been fixed, Cache-Control: public content is stored on > > disk. the pref still exists and, if enabled, also stores other SSL content on > > disk (except cache-control: no-store content, of course). > > > > So should we close this bug? > I vote NO on closing... I'd like to see caching of .js at least by default under SSL

(In reply to comment #21) > > I vote NO on closing... I'd like to see caching of .js at least by default > under SSL > There is no way to guarantee that this data is not sensitive (think JSON data being sent as JS). I think now that we obey cache-control public we should remove this pref.

(In reply to comment #22) > (In reply to comment #21) > > > > > I vote NO on closing... I'd like to see caching of .js at least by default > > under SSL > > > > There is no way to guarantee that this data is not sensitive (think JSON data > being sent as JS). I think now that we obey cache-control public we should > remove this pref. I think the following strategy may solve the problem: - if programmer SET "Cache-control" PURPOSIVE, then HTTPS will be cached (or not cached) as programmer want it. For example I do not set "Cache-control" on mydata.js (it won't be cached), but if (PURPOSIVE!) I set "Cache-control: private,max-age=86400" on myapplication.js, then it will be cached on hard disk. So the browser guarantee that the (HTTPS) data is not cached, but the programmer can overwrite it. Result: faster AJAX application start from cache, and controlled security by programmer.

(In reply to comment #23) > I think the following strategy may solve the problem: > - if programmer SET "Cache-control" PURPOSIVE, then HTTPS will be cached (or > not cached) as programmer want it. Please read comment 19 again.

As a web 2.0 developer and i disagree that the Cache-control parameter fix on bug 345181 is enough. There is generally 2 reason why this parameter should be true by default: 1) The fact is, that most web-apps does not set cache-control parameters on standard content like gifs and css (among many for the reason given in 2.). The current state of this parameter makes firefox allmost unusable on many web-based apps, especially ones making heavy use of graphics and this is the reason that i'm currently forced to recommend that users use IE (or lately alternately google chrome), since Firefox simply gives a very bad speed experience due to reloading of static contents 2) The reason that i cannot use the Cache-control parameter to fix this on my own apps, is that i for most of the time can't control them! Static content is mostly served to user directly by the httpd without ever touching my backend frameworks (for speed on server side). Sometimes i have possiblity of altering the httpd config to provide cache-control data and sometimes i have not. Never the less facts stands that quite a lot of web-based applications doesn't send these data for static content and expects the IE behavouir. So setting this parameter to true will allow for a better general user experience, while programmers easily can opt-out and ensure that dynamically generated confidential data cannot be cached. (Herby putting safety in hand of the programmer, who should think about it)

My bank recommends Firefox, for exactly the opposite reasons. They do not want anything to be cached, but unfortunately, IE gives the bad example. (apparently, the bank didn't know about Cache-Control either)

Bug 531801 switched browser.cache.disk_cache_ssl to true.