If you operate a website and want to enable HSTS, you should know about a few caveats:
1. You can't go back! As soon as a browser sees Strict-Transport-Security "max-age=31536000", it will refuse to load your site over HTTP for the next year.
2. The includeSubDomains option can cause problems in hard-to-predict ways. For example, Mailgun lets you set a CNAME for unsubscribe links. If a browser tries to load the HTTPS version, they'll get mailgun.com's cert, which is invalid for your domain.
3. Secure transport doesn't stop XSS, CSRF, etc. There are other headers such as Content-Security-Policy that can ameliorate some of these attacks. Also, sanitize!
4. HSTS is just one part of ensuring secure transport. It's also important to check your cipher suites. Not all TLS is created equal. SSL Labs is an extremely useful tool for testing your config: https://www.ssllabs.com/ssltest/analyze.html?d=floobits.com
If you're curious what the final result of all this paranoia looks like, take a look at the httpd config for floobits.com: https://gist.github.com/ggreer/9984770
You'll also notice mod_authn_yubikey. We require multi-factor auth (YubiKey + password) for our admin interface. There's tons of other stuff I could go into, but the real lesson is that security is like raking pine needles: You will never be done.
You can't go back! As soon as a browser sees Strict-Transport-Security "max-age=31536000", it will refuse to load your site over HTTP for the next year.
This sounds like a powerful way to DOS a site if you can set up a temporary https server on the domain and send this signal.
It's true that HSTS could be a way for someone who can set up a seemingly valid but nonetheless fake HTTPS listener on a domain to prevent people from later communicating with a genuine HTTP service on that domain.
Three remedies for this, with different degrees of applicability to different sites:
* Put a CAA record for your domain into your DNS (see https://tools.ietf.org/html/rfc6844) to prevent legitimate certificate authorities from issuing the cert to the impostor. (This only provides protection if the attacker doesn't control your DNS zone.)
* Actually switch to HTTPS!
* If this attack happens to you and you don't want to switch to HTTPS, run a legitimate HTTPS listener on your domain that clears the HSTS status and then redirects users back to HTTP.
The solution to that is every site should support HTTPS (or at least every site that has even the slightest risk that someone would want to do this to them).
1. You can't go back! As soon as a browser sees Strict-Transport-Security "max-age=31536000", it will refuse to load your site over HTTP for the next year.
Is this true? What if you send a new header with a max-age of 1 second, or send one with a garbage value?
I'm pretty sure I've seen a way for a website to disable HSTS, but I can't confirm right now.
Yes, but you'd have to serve that over HTTPS. And even then, how do you know that all the caches that have the older, longer expiration time have revisited and updated their cache? You won't, really, until that many seconds have pass.
Right, my point was just that there is a specified way for the server to tell the client not to use HSTS any more. Of course, the caveats you mention mean that to be certain, you would need to wait.
You can't go back in the sense that random end-users that visit your site will likely have that cached. In chrome, you can always visit about:net-internals and clear the HSTS cache. Probably not useful for random users, but good to know if you've found yourself locked out of something after messing around with settings.
If a site sends max-age=31536000 and then subsequently sends max-age=3, does the second header overwrite the first? If so, then you can in fact go back as long as you're willing to continue supporting HTTPS until the longest max-age header you ever sent has expired.
Comments
If you operate a website and want to enable HSTS, you should know about a few caveats:
1. You can't go back! As soon as a browser sees Strict-Transport-Security "max-age=31536000", it will refuse to load your site over HTTP for the next year.
2. The includeSubDomains option can cause problems in hard-to-predict ways. For example, Mailgun lets you set a CNAME for unsubscribe links. If a browser tries to load the HTTPS version, they'll get mailgun.com's cert, which is invalid for your domain.
3. Secure transport doesn't stop XSS, CSRF, etc. There are other headers such as Content-Security-Policy that can ameliorate some of these attacks. Also, sanitize!
4. HSTS is just one part of ensuring secure transport. It's also important to check your cipher suites. Not all TLS is created equal. SSL Labs is an extremely useful tool for testing your config: https://www.ssllabs.com/ssltest/analyze.html?d=floobits.com
If you're curious what the final result of all this paranoia looks like, take a look at the httpd config for floobits.com: https://gist.github.com/ggreer/9984770
You'll also notice mod_authn_yubikey. We require multi-factor auth (YubiKey + password) for our admin interface. There's tons of other stuff I could go into, but the real lesson is that security is like raking pine needles: You will never be done.
You can't go back! As soon as a browser sees Strict-Transport-Security "max-age=31536000", it will refuse to load your site over HTTP for the next year.
This sounds like a powerful way to DOS a site if you can set up a temporary https server on the domain and send this signal.
This DoS risk is documented in section 14.5 of the HSTS standard.
https://tools.ietf.org/html/rfc6797#section-14.5
It's true that HSTS could be a way for someone who can set up a seemingly valid but nonetheless fake HTTPS listener on a domain to prevent people from later communicating with a genuine HTTP service on that domain.
Three remedies for this, with different degrees of applicability to different sites:
* Put a CAA record for your domain into your DNS (see https://tools.ietf.org/html/rfc6844) to prevent legitimate certificate authorities from issuing the cert to the impostor. (This only provides protection if the attacker doesn't control your DNS zone.)
* Actually switch to HTTPS!
* If this attack happens to you and you don't want to switch to HTTPS, run a legitimate HTTPS listener on your domain that clears the HSTS status and then redirects users back to HTTP.
The solution to that is every site should support HTTPS (or at least every site that has even the slightest risk that someone would want to do this to them).
It would be if SSL was expensive. It isn't.
Is this true? What if you send a new header with a max-age of 1 second, or send one with a garbage value?
I'm pretty sure I've seen a way for a website to disable HSTS, but I can't confirm right now.
As per the spec, setting max-age=0 disables HSTS.
Yes, but you'd have to serve that over HTTPS. And even then, how do you know that all the caches that have the older, longer expiration time have revisited and updated their cache? You won't, really, until that many seconds have pass.
Right, my point was just that there is a specified way for the server to tell the client not to use HSTS any more. Of course, the caveats you mention mean that to be certain, you would need to wait.
You can't go back in the sense that random end-users that visit your site will likely have that cached. In chrome, you can always visit about:net-internals and clear the HSTS cache. Probably not useful for random users, but good to know if you've found yourself locked out of something after messing around with settings.
If a site sends max-age=31536000 and then subsequently sends max-age=3, does the second header overwrite the first? If so, then you can in fact go back as long as you're willing to continue supporting HTTPS until the longest max-age header you ever sent has expired.