
Yes, browsers do cache SSL resources, so please use Google's CDN - marketer
http://hoisie.com/post/yes_browsers_do_cache_ssl_resources__so_please_use_googles_cdn
======
joshfraser
The downside is that the secure versions take longer to download if you don't
get a local cache hit. I did a speed test and loaded jQuery 20 times from
Google using my local machine with an unprimed cache. For the http version,
the average load time was 90ms. For the https version, the average load time
was 192ms. That’s over twice as slow for the SSL version. Since you can't
guarantee the cache hit, it's a trade-off that doesn't have an obvious answer.

------
peterwwillis
So I have an idea. For HTTPS responses that are cached to disk, 1. do we care
about the security of the files on disk? 2. if so, do we do anything to
actually secure this content on disk?

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.

~~~
mcosta
Web developers should declare sensitive data no-cacheable.

~~~
peterwwillis
Also, this may be a completely separate issue, but shouldn't persistent
cookies set over https also be encrypted on disk in some way? If a bank
website was found to be setting persistent cookies over https, i'd sure want
the browser to be encrypting that cookie in _some_ way before putting it on my
hard disk. Again, I don't know if browsers already support this, but I think
they should.

------
brlewis
The article argued against says browsers don't cache SSL resources _to disk_.
This is not the same as saying they don't cache them at all. Can someone test
and report back the actual behavior?

EDIT: I see from an HN comment by the author that he did mean on disk.

~~~
briansmith
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
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.

~~~
briansmith
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>.

------
dstein
Sigh, you shouldn't be relying on Google for this anyways. No company should
be hosting files critical for your website except you.

~~~
gnaritas
There are good reasons to use the Google version.

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.

~~~
dstein
_A: Google is likely far more reliable.._

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.

~~~
dspillett
_No company, including almighty, do-no-evil Google should be trusted this
much._

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.

------
Periodic
The article mentions that the HTTPS link to the resources is now default on
Google's list of AJAX resources. I remember back in the day being warned that
SSL connections have an appreciable overhead and so you should avoid SSL use
unnecessarily. Is this no longer true? Has the overhead of <https://> become
negligible?

~~~
wizard_2
Yes it has become negligible. Google themselves have a nice talk about it. The
major overhead is in the initial handshake. Google themselves have published
how the major issues were in browser behavior (caching mostly) and not
connection speed or cpu cost.

~~~
daemin
Could you provide a link to that talk?

------
acqq
For those that don't know what CDN is here supposed to do:

[http://blog.patrickmeenan.com/2010/03/google-to-offer-cdn-
se...](http://blog.patrickmeenan.com/2010/03/google-to-offer-cdn-
services.html)

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.

------
grandalf
does anyone know if it's possible to use the Google Picasa CDN with ssl?

------
ezalor
Yes, if by "caching" you mean and only mean "caching on RAM".

