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?
