3 ms·
Why would that matter? HTTPS is about getting it over the wire securely... once it gets to the machine, there are no security guarantees.
by sgk284 16y ago
Why would that matter? HTTPS is about getting it over the wire securely... once it gets to the machine, there are no security guarantees.
- amalcon 16y agoThe 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.
- briansmith 16y agoIf 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.
- amalcon 16y agoI 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.
- briansmith 16y agoIf 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.
- amalcon 16y agoAgain, 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?
- andybak 16y agoWe probably want to remove any excuse for not switching to https. Perceived performance penalties, inconsequential or not, might hold back many sites.
- deleted 16y ago[deleted]
- acqq 16y agoI 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.
- philfreo 16y agoBut 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.
- acqq 16y ago> your bank account page would never reasonably have caching settings on it Are you aware how many banks don't have "ideal" developers? Is it easier to "change the whole world" or to use a browser with sane defaults?