Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I understand that sensitive data should not be cached (ie, you dont want to cache an HTML file with all of your bank account details in it), but there are some things that HTTPS protected sites should be able to cache (Javascript, CSS, images, etc). Tomcat doesn't seem to allow developers to explicitly define a file to be cacheable once SSL/TLS has been enabled, and I understand that even if they did the user's browser only uses an in memory cache for HTTPS sessions and discards everything once the session is over. With the whole Web 2.0 thing thats going on, it seems to me that site operators would be interested in this ability to reduce loads on their sites (as well as page load time) while maintaining the "green bar" in the user's browser that gives us all a warm, fuzzy feeling inside.

UPDATE: removed bits about validating the cached files with an HMAC since it would be useless. If the attacker is exploiting some form of hash collision then it doesnt matter if the hash is calculated with a secret key or not.

share|improve this question
    
Of course you could always run into a difficult user who runs with 0 cache. –  this.josh Sep 9 '11 at 8:17
1  
true, but most people leave their browser defaults alone, so I suspect he would be the exception rather than the rule –  senecaso Sep 9 '11 at 8:29
3  
"the user's browser only uses an in memory cache for HTTPS" - so not true. –  symcbean Sep 9 '11 at 12:04
    
Ya, I figured that out after reading the link posted by Hendrik below. Apparently that was only true for older browsers. –  senecaso Sep 9 '11 at 12:38
    
Also see stackoverflow.com/a/174510/632951 –  Pacerier May 5 at 15:24

1 Answer 1

up vote 13 down vote accepted

Use this header in your https response:

Cache-control: public

Or add ", public" to your existing Cache control header.

Use the Cache control: public directive to enable HTTPS caching for Firefox.

Some versions of Firefox require that the Cache control: public header to be set in order for resources sent over SSL to be cached on disk, even if the other caching headers are explicitly set. Although this header is normally used to enable caching by proxy servers (as described below), proxies cannot cache any content sent over HTTPS, so it is always safe to set this header for HTTPS resources.

Source: Google Page Speed

The posting HTTPS Performance Tuning says in the section "Tip #3: Use Persistent Caching For Static Content" that Internet Explorer can cache static resources over https connections, too.

share|improve this answer
    
Interesting, when I searched for this I found documentation indicating that even if you set the Cache-Control that browsers would end up discarding the cached data after it was shutdown. Do you know if the cached data is then verified in any way when the user returns to the site? Having a cached secure file is no good if it has been tampered with. –  senecaso Sep 9 '11 at 8:08
    
@senecaso, that why you need to explicitly define the "public" keyword. Using just the normal max-age in the cache-control-header is not sufficient. –  Hendrik Brummermann Sep 9 '11 at 8:15
    
According to the link you sent, setting it to "public" is a workaround for FF, but not other browsers. Earlier in the document, it mentions "Other older browsers may require that caching headers be set before they will fetch a resource from the cache; and some may never cache any resources sent over SSL." –  senecaso Sep 9 '11 at 8:17
    
And the second link has screenshots proofing that it works for IE, too. Just try it yourself. –  Hendrik Brummermann Sep 9 '11 at 8:18
    
After realizing that my HMAC verification idea was useless, this is the answer I was looking for. Thanks Hendrik! –  senecaso Sep 9 '11 at 10:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.