4 ms·

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 response

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.)

sdizdar 16y ago
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.
- ezalor 16y ago
  True.
- briansmith 16y ago
  They are different resources so they are cached separately. There is no standard that says that a cached response for https://foo.org/x https://foo.org/x can be used for a request to http://foo.org/x http://foo.org/x.
- davidu 16y ago
  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. Consider: https://foo/a.txt != http://foo/a.txt just like the obvious case of https://foo/b.txt != http://bar/c.txt All of those are considered unique URIs.
acqq 16y ago
> Firefox 4 caches HTTPS responses basically the same way it caches non-TLS HTTP responses. Can you please explain this sentence? I hope that doesn't mean "we now treat https just like http." Thank you.
- 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 ago
    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.
    - briansmith 16y ago
      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.
      - amalcon 16y ago
        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.
dspillett 16y ago
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)...

sdizdar 16y ago

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.

ezalor 16y ago
True.
briansmith 16y ago
They are different resources so they are cached separately. There is no standard that says that a cached response for https://foo.org/x https://foo.org/x can be used for a request to http://foo.org/x http://foo.org/x.
davidu 16y ago
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. Consider: https://foo/a.txt != http://foo/a.txt just like the obvious case of https://foo/b.txt != http://bar/c.txt All of those are considered unique URIs.

acqq 16y ago

> Firefox 4 caches HTTPS responses basically the same way it caches non-TLS HTTP responses. Can you please explain this sentence? I hope that doesn't mean "we now treat https just like http." Thank you.

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 ago
  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.
  - briansmith 16y ago
    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.
    - amalcon 16y ago
      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.

dspillett 16y ago

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)...