5 ms·
Websites Must Use HSTS in Order to Be Secure
- wglb 13y agoOne drastic solution if your web site has lots of IE users: Simply don't answer the phone on port 80. [Edit] Duh. As agentS points out, this won't work.
- sliverstorm 13y agoI don't think that's helpful. Perhaps more along the lines of putting a flat redirect on port 80, with no content. (It sounds like this attack depends on a complete version of the website being available over port 80)
- agwa 13y ago> (It sounds like this attack depends on a complete version of the website being available over port 80) No, it doesn't. An attacker can always connect to the website over HTTPS and proxy the content to the victim over port 80.
- sliverstorm 13y agoHmm, yes, of course you are correct. I'm not sure why I was thinking that wouldn't be a risk.
- agentS 13y agoThe attacker will merely reply on your behalf. Does not improve the situation.
- awj 13y agoThe real drastic solution is to disable HTTP for the entire internet and stop implicitly trusting the identity of servers. Until we decide that is worthwhile we're just going to be patching a leaky boat.
- dazbradbury 13y agoCan't a MITM (as described in the article) strip out any HSTS headers automatically, thus thwarting this quite simply? As with HTTPS, you need a shared secret before 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?
- agwa 13y agoOn the very first connection from the browser to the website, yes. But the browser saves the HSTS setting (for the time specified by the HSTS header's max-age value) so future connections go straight to HTTPS. Chrome and Firefox also ship with a baked-in HSTS preload list containing sites that should always use HTTPS, without depending on the HSTS header: http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json http://src.chromium.org/viewvc/chrome/trunk/src/net/http/tra...
- sliverstorm 13y agoOk, so how about the attacker intercepts the https request with a self-signed cert, modifies the stored HSTS header by issuing a new max-age of 0.25 second, and includes a redirect back to http:// http://? This just kind of seems unwinnable, a million holes.
- agwa 13y ago> Ok, so how about the attacker intercepts the https request with a self-signed cert, modifies the stored HSTS header by issuing a new max-age of 0.25 second, and includes a redirect back to http:// http://? HSTS disallows the user from overriding the certificate warning and accepting a self-signed cert.
- sliverstorm 13y ago(You just edited your comment, didn't you) Well, that's a good detail then. Does it in fact reject connections to self-signed certs? Or just disallow you from accepting the broken cert? Because the real goal would just be to get the user onto http:// http:// as quick as possible, and then the untrusted warning is gone.
- chris_mahan 13y agoAlternatively, 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. Any attempt to defeat that model will be handled by the US Postal Inspection Service, (see also https://postalinspectors.uspis.gov/aboutus/mission.aspx https://postalinspectors.uspis.gov/aboutus/mission.aspx)
- chris_mahan 13y agoNote that if you take their money and don't ship their product as described, the US Postal Inspection Service will come after you. It protects both sides from fraud.
- mch0lic 13y agoHTTPS sounds great and st 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
- ggreer 13y agoIf 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 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 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.
- jackpirate 13y agoYou 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.
- tootie 13y agoMy current client is insisting that all https traffic be served over a separate subdomain.
- WhiteDawn 13y agoFor anyone wondering general best practices for setting up HTTPS on Apache/nginx I found this to be a really great resource https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS
- marcosdumay 13y agoOf 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).
- agwa 13y agoFirefox stopped showing favicons in the URL bar. For HTTP you see a globe; for HTTPS, a padlock.
- marcosdumay 12y agoThat's good, and I didn't notice.
- conductor 13y agoI 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.
- borplk 13y agoIs it not effectively like someone hand-typing the address with HTTPS? how does it expose anything?
- agwa 13y agoBriefly: a page can embed a hidden image with a http:// http:// URL (with a different hostname, used just for tracking purposes). If that image gets loaded over HTTPS, it means the site has been visited before. If it loads over HTTP, the site hasn't been visited before; it then redirects to the HTTPS version and sends a HSTS header so on the next visit it goes straight to HTTPS. That stores one bit of information. Repeat 32 times (with 32 different host names) and you can store a unique 32-bit tracking number that persists even when cookies are cleared.
- derefr 13y agoOne 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 https://news.ycombinator.com/ https://news.ycombinator.com/ on a fresh connection to a wi-fi hotspot, and you just get a connection error.
- hdevalence 13y agoThere's no functional difference between craptive portals and a MITM attack, so this definitely seems like a feature...
- schoen 13y agoSome people have been thinking about creating a standard to distinguish between the two so that captive portals won't have to do a MITM attack (that browsers currently correctly defend against). One idea might be to have a different protocol through which the captive portal can indicate its presence and declare itself as a captive portal, entirely or almost entirely outside of the HTTP or HTTPS session. Getting the UI right is pretty challenging, though. It's not even completely clear what getting it right would mean. Even if the user clearly understands that they're interacting with some network operator rather than, say, Gmail or their organizational webmail server, the user still has no way to know whether the portal they're talking to is actually operated by the operator of the network that they think they're connecting to!
- deathanatos 13y agoI've wondered this too. Doesn't DHCP support extensible options? Couldn't you just send an option that said, "hey, crappy portal welcome site at {URL}"? It'd be fixed to a particular webpage (so, you can't use another protocol), but that's the state of things today.
- derefr 13y agoIt seems like there are only two things captive-portals are "for", though: accepting EULAs, and presenting a login form for the proxy. Both of these could be better if built into browser/OS chrome.