I've been wondering what max-age should the HTTP Strict Transport Security header have.

Both paypal and lastpass sites leave it very low: 500 (seconds = bit over 8 minutes)

market.android.com has it set much higher: 2592000 (seconds = 30 days).

Do I correctly guess that the value should be at least few days? Doesn't a 8-minute timeout defeat its purpose? Are there any other downsides apart from privacy concerns (you can check during the next month if someone visited particular page by looking at a browser cache)?

1 Answer 1


From the IETF draft [ https://datatracker.ietf.org/doc/html/draft-ietf-websec-strict-transport-sec-06 ]:

10.1 HSTS Policy expiration time considerations

Server implementations and deploying web sites need to consider whether they are setting an expiry time that is a constant value into the future, e.g., by constantly sending the same max-age value to UAs.

For example, a max-age value of 778000 is 90 days:

Strict-Transport-Security: max-age=778000

Note that each receipt of this header by a UA will require the UA to update its notion of when it must delete its knowledge of this Known HSTS Host. The specifics of how this is accomplished is out of the scope of this specification.

Or, whether they are setting an expiry time that is a fixed point in time, e.g., by sending max-age values that represent the remaining time until the expiry time.

A consideration here is whether a deployer wishes to have the signaled HSTS Policy expiry time match that for the web site's domain certificate.

Additionally, server implementers should consider employing a default max-age value of zero in their deployment configuration systems. This will require deployers to wilfully set max-age in order to have UAs enforce the HSTS Policy for their host, and protects them from inadvertently enabling HSTS with some arbitrary non-zero duration.

Therefore, since the browser will update it's stored HSTS max-age on every max-age header recieved [over https], going with the longer time won't really cause any of this bad cache horror story that the gossip talks about. The only issue is if the cert changes. However, site owners should be aware of this and should have the max-age set low (5-8 minutes) right before (a full day or so) the cert change is done due to expiration. However, this is only to deal with an incoming cert expiration (which is mostly avoided by replacing the cert with a new one before the last minute), as can be seen by:

14.6 Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack

If an attacker can convince users of, say, https://bank.example.com (which is protected by HSTS Policy), to install their own version of a root CA certificate purporting to be bank.example.com's CA, e.g., via a phishing email message with a link to such a certificate. Then, if they can perform an attack on the users' DNS, (e.g., via cache poisoning) and turn on HSTS Policy for their fake bank.example.com site, then they have themselves some new users.

Which shows that cert change in the middle of a broswer's HSTS "session" would not cause problems unless there were problems with the cert (validation warnings or errors). This would render the whole point of your question moot because it assumes that browsers store some piece of information related to the cert sent with the HSTS header response to validate against the HSTS host. As the draft makes no mention of such a concept, I would say that it is an invalid assumption.

However, storing cert information to be used against HSTS hosts can be done with public key pinning. But this would be done at a "factory" level or by the user manually, and as such would also have no way of updating via a HSTS host. [see http://www.imperialviolet.org/2011/05/04/pinning.html for more information]

To answer your last question, there is a privacy concern in the use of HSTS to track users. It works by using javascript to check if a resource in a list of websites that is enumerated through is loaded via https even though it is specified as http. The point of having a moderately low max-age in this case would be to have the entries cleared so that user tracking would be hindered. [see http://haxsys.net/2011/04/the-double-edged-sword-of-hsts-persistence-and-privacy/ for more information]

@Jesper Mortensen: HSTS causes the browser to rewrite all http requests to https before sending them. Therefore you shouldn't have both http and https accesses to a given domain. And anyone implementing HSTS SHOULD (RFC2119) not have a real http facing site (ie redirect on http requests to https via 301 or do something else [see section 6.2]). And mixed context stuff (http to other non-ssl non-hsts domain resources are a problem that is supposed to be dealt with on an implementer basis (by both server and browser)). Also try not to mock its draft status as it is implemented in both Firefox and Google Chrome(ium) [ie. ~55% of all browsers].

  • HSTS doesn't protect against rogue CAs, it protects against bugs in redirection, application and users ignorance as far as entering full https://... when going to a banking site. Cert pinning is something completely different Jul 26, 2011 at 0:05
  • @Hubert Kario: The point was wade to state that if a cert has no warnings or errors (even if it is malicious) it's going to work against a user who is still within his/her HSTS time limit. Your question assumes something that is not true [which is closer to what pinning does]. And it absolutely does not protect against "bugs in redirection."
    – Jeff
    Jul 26, 2011 at 7:06
  • 1
    by "bugs in redirection" I meant web application, not the browser. That is, the application by mistake puts http:// links in HTML Jul 26, 2011 at 11:07
  • 1
    @Hubert Kario:HSTS will only change links to the HSTS host domain. This is often not enough.
    – Jeff
    Jul 26, 2011 at 14:02
  • that's true, haven't thought about this Jul 26, 2011 at 14:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .