Avoid “Do not save encrypted pages to disk”

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:

1. File downloads.
2. When an add-on or other code sets the flag INTERNET_FLAG_NEED_FILE on a request.

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.

-Eric

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.

Comments

• Anonymous
  May 06, 2011
  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.

• Anonymous
  May 06, 2011
  @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.

• Anonymous
  May 22, 2011
  Here's a real-world story about how that setting caused unexpected and undesirable consequences: blogs.technet.com/.../sticking-with-well-known-and-proven-solutions.aspx

• Anonymous
  May 24, 2011
  The comment has been removed

• Anonymous
  May 24, 2011
  @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.

• Anonymous
  May 24, 2011
  @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?

• Anonymous
  May 24, 2011
  @Zdzich: Yes, when you browse InPrivate, all cache entries created in that mode are wiped when you exit the InPrivate instance.

• Anonymous
  May 27, 2011
  @EricLaw: Does "wiped" mean securely deleted? [Ericlaw: Earlier comments address the threat model that involves a local attacker].

• Anonymous
  May 27, 2011
  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.

• Anonymous
  June 27, 2011
  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 -> Reset
   2. Close IE completely
   3. Open IE
   4. Tools -> Advanced -> Security -> Check the Do not save encrypted pages to disk
   5. Close IE again (make sure the iexplore.exe is completely gone)
   6. Re-start IE
   7. 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...

• Anonymous
  June 27, 2011
  @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.

• Anonymous
  June 27, 2011
  @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!

• Anonymous
  August 14, 2011
  Hi Eric, 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: Cache-Control: no-store,no-cache expires: -1 Pragma: no-cache (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. Thank you, D. Malone.

• Anonymous
  August 15, 2011
  @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).

• Anonymous
  August 15, 2011
  Hi Eric, 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. Best regards, D. Malone.

• Anonymous
  October 30, 2011
  Hi Eric, Does the option “Do not save encrypted pages to disk” prevent persistent cookies from being saved also? Thanks BM

• Anonymous
  October 30, 2011
  @BM: No.

• Anonymous
  January 23, 2014
  The comment has been removed

• Anonymous
  January 24, 2014
  The comment has been removed

• Anonymous
  March 25, 2014
  The comment has been removed

• Anonymous
  May 15, 2014
  The comment has been removed