Yes, browsers do cache SSL resources, so please use Google's CDN
hoisie.com
hoisie.com
If 2 is 'No', could we perhaps encrypt the content with the SSL cert (or some piece[s] of it) before written to disk? Say you have an app you want/need to benefit from caching but the cached data contains sensitive information you'd like to make it harder to get at from a long-term perspective. Take some unique bits (or lots of bits; they're kind of small) and encrypt the cached data with it, and make a hash so you can reference where this cached item came from without explicitly noting where it came from. This would let you store the data with the knowledge that if somebody recovered a hard drive with this old data it would be difficult for them to figure out where the cached data came from and how to encrypt it.
I realize i'm basically asking to use public information to encrypt private data. This can't be too difficult to 'hack' around but you'd need to know what website and certificate created the cached copy (so those entries should probably leave the 'history' as soon as the browser exits). I'm not too familiar with SSL certs in general so to add extra protection you can add something like Firefox's Master Password to the encryption scheme so it's "genuinely" encrypted without data which can be found or guessed like in the SSL cert.
Sorry if this is off-topic, just popped in my head and now i'm curious.
EDIT: I see from an HN comment by the author that he did mean on disk.
Consider:
https://foo/a.txt != http://foo/a.txt https://foo/b.txt != http://bar/c.txt
Can you please explain this sentence? I hope that doesn't mean "we now treat https just like http." Thank you.
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.
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.
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.
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?
Writing every https response to the disk is just wrong.
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?
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)...
A: Google is likely far more reliable than your dinky little outfit, so odds are very very high it'll be up and absurdly reliable.
B: If you use the Google version, it's probably already in your user's cache saving you nearly an 80k download for a common library and making the first hit to your site potentially much faster.
It's not about reliability. It's about trust. When you cross-site script yourself by giving Google access to the contents of every page on your site, you are entrusting this company with your data, and all your customer's data.
No company, including almighty, do-no-evil Google should be trusted this much.
B: If you use the Google version, it's probably already in your user's cache saving you nearly an 80k download
This might be offset slightly by your web browser having to make a separate HTTPS connection to a different "secure" host. If you are this concerned about JavaScript load times you should bundle all required javascript into a single file -- one HTTP request to one server will always beat many requests to many servers.
It isn't just about trusting the CDN: relying on popular public static resources like this increases your vulnerability to DNS poisoning attacks.
If some malware manages to redirect requests for Google's static content servers to their servers they could inject a key-logger or username/password/credit-card info scanning code into every site (even small and/or low profile sites that would otherwise not be as likely to be targeted) using that as a source for libraries like jQuery that the infected users visit.
http://blog.patrickmeenan.com/2010/03/google-to-offer-cdn-se...
If I understood it correctly, the idea is to refer to the web resources in html in such a way to let the clients access them with the minimal possible latency, no matter where the clients are.