Please read my blog's comment policy here.
Internet Explorer has an Advanced option named Do not save encrypted pages to disk. By default, this option is unchecked (except for Windows Server systems) and I recommend you leave it that way.
In IE9, this option does exactly what it says it does—resources received from HTTPS URLs are not placed in the Temporary Internet Files Cache and temporary files are not created for these resources. This option is universal for HTTPS responses; their headers (e.g. Pragma, Cache-Control) are not consulted.
While that might sound appealing to some readers, it’s important to realize that this will break any scenario where a file is needed.
There are two key scenarios when a file is required:
If a file download is attempted from HTTPS when this option is set, the secure download will fail:
Similarly, some plugins like Flash will set the NEED_FILE flag when issuing a HTTPS request, and those requests will fail in this configuration. For instance, when Pandora attempts to login, their XML request fails:
In IE8 and lower, the behavior of the checkbox was much more complicated, modified by a number of cumulative updates over the years. At a high-level, if a Pragma: no-cache was present on the HTTPS response, then no cache or temporary file would be created. If other no-cache headers were present, then the cache or temporary file might be created based on a very complicated set of logic, involving whether the response was compressed, and depending on the ordering of the no-cache and no-store tokens in the response’s Cache-Control header.
If you do not want HTTPS-delivered content to be stored in your cache, then you are better off setting the Empty temporary internet files folder when browser is closed option instead. Downloads and Flash applications will work properly, and IE will clear the cache completely when the browser is closed. If you're worried about local attacks with full access to your hard drive, enable BitLocker Drive Encryption, which will protect not only your cache files, but also your swap file.
Update: In IE10, the Do not save encrypted pages to disk option now behaves differently. Instead of trying to prevent HTTPS resources from being saved to disk, the option will delete cached-from-HTTPS resources from the cache when the browser is closed. This helps ensure that the browser works correctly even when this setting is enabled. The checkbox was slated to be retitled "Clear HTTPS cache when browser is closed" but we unfortunately ran out of time.
But when the temporary internet files folder is being emptied then it's not done using securely, ie. overwriting the bytes at least once. On top of that, if shouldn't anyone who uses this option for a valid reason also deactivate the page file or put it on volatile memory?
All in all, it seems like this option is useless, if somebody wants to prevent somone with pysical access to spy on him, he needs to encrypt his whole system drive using BitLocker, TrueCrypt or therelike.
@Pete: Yes, that's correct. If a user is concerned about local attacks and presume full access to their drive, using BitLocker Drive Encryption is the correct way to go.
Here's a real-world story about how that setting caused unexpected and undesirable consequences:
@EricLaw: And how this problem is resolved in Mozilla Firefox nad Google Chrome? There are no such problems using those browsers. Should I assume that encrypted pages are allways cached to disk? I haven't found any settings regarding this topic in those browsers. Can you say something about this?
@Zdzich: Like IE, Firefox and Chrome both will cache cacheable HTTPS resources by default. I have no idea whether or not those browsers will function completely correctly if you change their about:config options to prevent HTTPS caching entirely.
@EricLaw: And if I have disabled “Do not save encrypted pages to disk” option but for example for internet banking i will use InPrivate mode of Internet Explorer will it cache bank site for this session and clear cache when I exit (close browser) InPrivate mode?
@Zdzich: Yes, when you browse InPrivate, all cache entries created in that mode are wiped when you exit the InPrivate instance.
@EricLaw: Does "wiped" mean securely deleted?
[Ericlaw: Earlier comments address the threat model that involves a local attacker].
There is one work around if you have enough memory. Using a program called dataram ramdisk, you can set a virtual disk in ram, and you can change the IE temp files folder to that virtual drive. The company claims a significant increase in browsing speed, but I didn't notice much difference at all.
Dear Eric, I have observed a related issue which is inconsistent behavior of the said option - namely the https download fails ONLY the first try and the it starts working? I reported this to the Connect community about 6 months ago, and my ticket was closed after I was redirected here (connect.microsoft.com/.../first-download-over-https-with-do-not-cache-files-over-ssl-on-always-fails) Anyway, to reproduce:
1. Reset all IE settings (clean slate) Tools -> Advanced -> Reset2. Close IE completely3. Open IE4. Tools -> Advanced -> Security -> Check the Do not save encrypted pages to disk5. Close IE again (make sure the iexplore.exe is completely gone)6. Re-start IE7. Try downloading the file by pasting: e-justice.europa.eu/.../jscal2.css
You should see the error message as reported. Try downloading the same resource - success (?) Looks like a bug to me with unclear consequences re caching the file.
Any ideas what's going on here? Reproducible on IE8, I'm pretty sure I reproduced on IE9 too but couldn't today...
@Alexander: IE8's code is significantly different than IE9s, and sometimes in IE8 HTTPS-delivered files were permitted to be cached with the "Do not cache encrypted pages" setting enabled. IE9s is exactly as I describe it above, and the download will always fail.
@EricLaw - thanks for the rapid response, that about explains it... By the way I've noticed that hitting the Retry download button after a failed https download issues very different request headers (e.g. Accept-Language: disappeared) altogether which doesn't seem right to me. I'll report this separately. Cheers and thanks for this blog!
I wonder if I could post a question regarding the ordering of Cache-Control directives:
I have an ASP.net (HTTPS://localhost/etc etc) application.
Its HTTP response headers are configured in IIS as follows:
(Additionally, these directives are also set in the ASP.NET code.)
The Internet Explorer option "Enable automatic crash recovery*" was off.
Using IExplore 8.0.6001.18702, I found that some partial aspects of the application's page were cached to disk.
(Winhex from www.winhex.com found the partial data)
Running the same code on a separate machine, using IExpxlore 8.0.7601.17514, WinHex found no partial pages.
(Also, this application does not result in partial data being stored to the cache if I use Firefox)
I noticed that you mentioned above that the order of the Cache-control directives is important:
"If other no-cache headers were present, then the cache or temporary file might be created based on a very complicated set of logic, involving whether the response was compressed, and depending on the ordering of the no-cache and no-store tokens in the response’s Cache-Control header.."
Ideally, I would be very much interested in getting the exact ordering of the no-cache and no-store directives in the HTTP response headers to prevent this partial caching in IExplore 8.0.6001.18702.
@D. Malone-- Where, specifically, did you see the data? It's generally not possible, on a commodity operating system, to prevent data in memory from landing on the disk, as the virtual memory subsystems of all major operating systems will periodically swap pages out from the working set (memory) to the swap file (hard disk).
This data was found in "free space" on Drive C:
The PageFile was configured to have a fixed size.
The machine was running XP and was not running the latest version of IE8.