If you operate a website and want to enable HSTS, you should know about a few caveats:<p>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.<p>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.<p>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!<p>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: <a href="https://www.ssllabs.com/ssltest/analyze.html?d=floobits.com" rel="nofollow">https://www.ssllabs.com/ssltest/analyze.html?d=floobits.com</a><p>If you're curious what the final result of all this paranoia looks like, take a look at the httpd config for floobits.com: <a href="https://gist.github.com/ggreer/9984770" rel="nofollow">https://gist.github.com/ggreer/9984770</a><p>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.
Of course, it would help if browsers stopped letting sites put an image at the same place they show the locker (like they used to)... But that would require a few more pixels for canvas, and security is a secondary concern (just like usability).
Can't a MITM (as described in the article) strip out any HSTS headers automatically, thus thwarting this quite simply?<p>As with HTTPS, you need a shared secret <i>before</i> communication begins for anything like this to combat MITM attacks. Unless the browser communicates with a secure server to assess whether the website should be sending HSTS headers... Is that the idea?
One interesting thing I've noticed about HSTS (which is probably a good thing in the long run, but kind of painful for now): it breaks wi-fi capture-portal redirects. Try to load <a href="https://news.ycombinator.com/" rel="nofollow">https://news.ycombinator.com/</a> on a fresh connection to a wi-fi hotspot, and you just get a connection error.
I would like to point out that HSTS is not compatible with private browsing because by saving the information that the particular site must be accessed by HTTPS the browser exposes the fact that the said site was previously accessed. I hope we will eventually come to required secure HTTP by default with the next versions of the protocol.
For anyone wondering general best practices for setting up HTTPS on Apache/nginx I found this to be a really great resource<p><a href="https://wiki.mozilla.org/Security/Server_Side_TLS" rel="nofollow">https://wiki.mozilla.org/Security/Server_Side_TLS</a>
One drastic solution if your web site has lots of IE users: Simply don't answer the phone on port 80.<p>[Edit] Duh. As agentS points out, this won't work.
Alternatively, make a plain html website and don't ask users to log in and don't track them with cookies, etc. If you want to collect money from them, make a real product and mail it to them after they sent you a postal money order.<p>Any attempt to defeat that model will be handled by the US Postal Inspection Service, (see also <a href="https://postalinspectors.uspis.gov/aboutus/mission.aspx" rel="nofollow">https://postalinspectors.uspis.gov/aboutus/mission.aspx</a>)
HTTPS sounds great and s<i></i>t but HTTPS won't help you if you dumb enough to execute shell commands as a root on your server based on unfiltered user form inputs... Unfortunately, I noticed that lots of 'idea guys' trust the dev they hire first even if they have absolutely no skills whatsoever. lOOOl