When should HSTS be enabled?

Question

If I am running a HTTPS only service, is there any reason not to enable HSTS? Is there a strategy to test HSTS without permanently enabling it or a way "out of" HSTS?

Answer 1

I'd like to add to Mike's answer the warning, that you are probably not running an HTTPS-only service. The reason is that when your server doesn't listen on port 80 then if you only type in the domain and not the protocol (stackoverflow.com instead of https://stackoverflow.com) your browser will not automatically try to connect on port 443 (https) and show a connection error. Thus for most sites an HTTPS only service is out of the question.

The classical way to ensure an https connection by forwarding every http page to an https page via 301/303 forwards is not a sufficient replacement for HSTS. In fact HSTS was build for that case exactly. The reason is that many bookmarks and links will still point to http and every time a user enters a URL without specifying the protocol - which is always - the browser will first try the http connection. An active attacker can hijack that first connection and never forward the user to the https site.

To give you a more vivid image of such an attack imagine a state who spoofs every DNS request to twitter and answers with its own IPs. When it receives an https request it forwards it to twitter without any action (and chance for interception). But when it receives an http request it uses the tool ssl strip Mike has mentioned to transparently forward the content of the connection to twitter's TLS port. Neither the user nor twitter notice that anything is off (except for the very alert users who checks for TLS encryption) but the state has access to every login password.

HSTS can protect those users that have had a legitimate https connection with the server before and have already seen an HSTS header. The header instructs the browser to exchange every http url of the domain with an https url itself (before an http connection is established at all) and deny any unencrypted connection to this domain. Thus in the scenario above almost all users will not end up on the compromised http connection and are safe against the nation wide attack.

Answer 2

From a defense in depth perspective, you should still enable HTTP Strict Transport Policy (HSTS). There are some issues that could crop up in the future that would benefit from HSTS, including:

• Server misconfiguration, where HTTP is accidentally turned on. There's one site I visited recently that takes credit card details, it has a HTTPS site but Google links to their HTTP site so depending on how you got there, you could be submitting your details in the clear.
• Malicious attacker poisons or hijacks DNS records to redirect the client to their own HTTP-only server, perhaps in conjunction with an ssl strip attack.

You should also ensure a sufficiently long HSTS lifetime, e.g. a year or more.

You can disable support for HSTS by setting the max-age to 0. You'll need to leave this header in place for as long as you had originally set the value. E.g. If you had set it to 2 years, and change your mind, you'll need to leave max-age=0 for at least 2 years (and continue to offer an HTTPS service on that domain) so past clients won't have any issues connecting to it.