Websites Must Use HSTS in Order to Be Secure

https://www.eff.org/deeplinks/2014/02/websites-hsts

by zoowar • 12 years ago

52 53 12 years ago

eff.org

wglb• 12 years ago

One 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.

sliverstorm7• 12 years ago

I 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)

agwa8• 12 years 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.

agentS• 12 years ago

The attacker will merely reply on your behalf. Does not improve the situation.

awj• 12 years ago

The 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.

dazbradbury2• 12 years ago

Can'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?

agwa8• 12 years ago

On 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/tra...

sliverstorm7• 12 years 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://?

This just kind of seems unwinnable, a million holes.

dazbradbury2• 12 years ago

Got it. So not 100% full-proof (not that anything is).

This also means that once you switch to using HSTS, you can't go back.

regecks• 12 years ago

It seems silly that Chromium and Firefox now have separate HSTS lists (though Firefox's was seeded using the Chromium list [1]).

At the moment, these lists appear to be b) tied to specific browsers 2) tied to specific releases of those browsers.

Would it be viable to run some kind of global open registry where any website can be registered for mandatory HSTS? That way, every individual website owner doesn't need to submit a bug to Chromium and Mozilla - the browser just needs to securely connect to the registry and download the latest list. Or maybe DNSSEC can help ...

Maybe work on this is already underway, but I was reading some MLs a few weeks ago and I didn't see any forthcoming solutions ...

1. https://blog.mozilla.org/security/2012/11/01/preloading-hsts...

tootie2• 12 years ago

You can configure your http vhost to do nothing by send redirects to https and never serve content.

chris_mahan2• 12 years ago

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.

Any attempt to defeat that model will be handled by the US Postal Inspection Service, (see also https://postalinspectors.uspis.gov/aboutus/mission.aspx)

chris_mahan2• 12 years ago

Note 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• 12 years ago

HTTPS 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• 12 years ago

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.

jackpirate• 12 years ago

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.

thirsteh• 12 years ago

It would be if SSL was expensive. It isn't.

eridius2• 12 years ago

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).

schoen3• 12 years ago

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.

eridius2• 12 years ago

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.

shuzchen• 12 years ago

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.

notJim• 12 years ago

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.

hdevalence3• 12 years ago

As per the spec, setting max-age=0 disables HSTS.

tootie2• 12 years ago

My current client is insisting that all https traffic be served over a separate subdomain.

WhiteDawn• 12 years ago

For 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

marcosdumay2• 12 years ago

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).

agwa8• 12 years ago

Firefox stopped showing favicons in the URL bar. For HTTP you see a globe; for HTTPS, a padlock.

marcosdumay2• 12 years ago

That's good, and I didn't notice.

conductor• 12 years ago

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.

borplk• 12 years ago

Is it not effectively like someone hand-typing the address with HTTPS? how does it expose anything?

agwa8• 12 years ago

Briefly: a page can embed a hidden image with a 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.

derefr2• 12 years ago

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 https://news.ycombinator.com/ on a fresh connection to a wi-fi hotspot, and you just get a connection error.

hdevalence3• 12 years ago

There's no functional difference between craptive portals and a MITM attack, so this definitely seems like a feature...

schoen3• 12 years ago

Some 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!

Websites Must Use HSTS in Order to Be Secure

Related Stories