Firefox 3.x caches (to disk) HTTPS responses with Cache-Control: public. Firefox 4 caches HTTPS responses basically the same way it caches non-TLS HTTP responses. Apparently, IE and Chrome are also doing this more aggressive caching. (I work in Mozilla's Platform/Networking team.)
I don't want the browser that stores to the disk the page from my bank account (that was anyway generated just to be displayed at that moment and never reused) just because "HTTPS is about getting it over the wire securely." I prefer the browser defaults that are sensible.
Writing every https response to the disk is just wrong.
But your bank account page would never reasonably have caching settings on it. We're talking about static assets specifically set to be cached - images, js, css.
The first thing that comes to mind is that it opens up a timing attack (with JavaScript; it might be possible, though more difficult, with server logging). An attacker could find out which (secure) pages you've accessed. Given that there are link coloring tricks to do this anyway, it might not be so bad, but I was under the impression that browsers are starting to close that hole.
Of course, you could always cache-control this behavior away on the server, but not if you don't know about it. I, for one, am glad I found out.
If you don't want your HTTP requests to be cached and/or stored, then you really must use the appropriate Cache-Control directives.
IIRC, most browsers have cached HTTPS resources in memory (if not on disk) for a long time, so these kinds of side channel attacks have always been possible.
More generally, TLS is not good at handling side-channel (timing, caching, size measurement) attacks. If you want to mitigate side channel attacks then you need to do a lot of tedious work (that is practically impossible with current mainstream tools) at the application/HTTP layer on the server.
I upvoted you: everything in your comment was correct, on-point, and good advice. I'm more worried about all the people who don't follow the best practice. I know a guy who used to run web servers for dozens of clients, who didn't know about HTTP headers before I told him.
For what it's worth, in-memory caching is a totally different animal. You can expect the in-memory cache to keep a typical object for minutes or hours, depending on usage patterns. You can expect the disk cache to keep a typical object for days or weeks, across browser restarts and even system reboots.
If this caching allows a website to switch from using HTTP to HTTPS within its budget, then I think the net effect is very positive. We can't have bad website administrators/developers holding back real security improvements with their incompetence. Really, caching is a very small security impact compared to other problems that such an administrator is likely to cause.
Again, absolutely right. Remember, though, that we're not talking about the capability here: we're talking about the default. A (well-run) website can get all the caching benefits by including a HTTP header. The article is about a well-run website that does exactly this. The default only matters at all for poorly-run websites.
Given that poorly run websites are considerably less likely to be worried about scaling issues, the caching is mostly inconsequential. So, would we prefer to give the poorly-run website a mostly inconsequential security benefit or a mostly inconsequential scaling benefit?
Question: The article says that if a resource is accessed as 'http:' and then as 'https:', then the second access will not hit the cache. Is that true? Thanks.
They are different resources so they are cached separately. There is no standard that says that a cached response for https://foo.org/x can be used for a request to http://foo.org/x.
Those would be different URIs, and thus different URLs, and thus have different caching policies. URIs (and in turn URLs) must be consistent for caching to apply.
It would be interesting to see a comparison of how common and soon-to-be-common browsers [FF3/3.5/4, IE6/7/8/9, Chrom(e|ium), common mobile browsers, ...] deal with HTTPS content by default and in response to relevant headers. No persistence, short-term persistence (not re-requesting objects currently in use elsewhere in the current document and/or other open windows/frames), up-to-session-long persistence (RAM cache), or long-tern persistence (disk cache).
I suspect there will be quite a range of behaviours, especially if you consider IE6 (which unfortunately I have to, as do many others) so a bit more consideration is needed before jumping to change expectations of static content access speeds.
Another bit of my research to add to the list of things that'll get looked into when I have some free time (i.e. when hell freezes over)...
