HSTS vs only https with secure cookie

Question

Is it good enough a protection if my site is serving on https with secure session cookie and redirects any attempts for http urls to https?

What kind of security holes can i be exposed in this setup to for which i cannot live without setting the HSTS header?

Answer 1

This strategy protects against passive eavesdropping by making it hard for an attacker to trick your user into using something other than SSL to access your site. It also probably ensures that any bookmarks users store will point to the https URLs, which is good. However, HSTS still offers advantages in the event of a man-in-the-middle attack.

The core of the problem that HSTS tries to solve is that the browser doesn't know whether a given site should be using SSL or not. And most users don't explicitly try SSL first; if they type in a URL, they generally go to the non-SSL http site first, and usually they're just following links. If an attacker can trick your user into going to your site via an http URL and can sit in the middle of the user's traffic (by being their wireless AP, for example), that attacker can launch a man-in-the-middle attack against your site by proxying the user's traffic to your site and presenting the site to the user without SSL (this is a type of downgrade attack). Since the user won't see SSL, their browser won't recognize that the attacker doesn't have a valid certificate for your site and that they're not connecting to your site directly. (A more complicated approach would be to intercept the SSL traffic and present a self-signed or otherwise invalid certificate for your site, but this will normally result in browser warnings.)

In this scenario, redirecting non-SSL users to SSL or setting the secure flag on cookies doesn't actually help you very much. The man-in-the-middle attacker will be connecting to your SSL site (and proxying the user's actions to it), and will just remove the secure flag from your cookies when passing them along to the user.

The attacker can, of course, also remove the HSTS header. The point of the HSTS protocol, however, is that if the user had ever successfully gone directly to your site in the past, their browser will remember that your site sent HSTS. If they then later connect to your site and find that it's not using SSL or that the browser can't verify the certificate, the browser will throw an error and refuse to continue. This will prevent the attacker from downgrading your site to non-SSL if the browser supports HSTS and has your site recorded as requiring SSL.

Wikipedia has a fairly good discussion of this, which I think is somewhat clearer than the discussion in the RFC.