The limitation with the approach (of HTTP=>HTTPS redirects) is that your average coffee-shop-wifi-user may not notice if their connection does not upgrade to HTTPS due to malicious interception of their connections.

With HSTS, once they've connected to the server over HTTPS once (e.g. at home), every connection from that browser will be immediately upgraded to HTTPS before even trying HTTP.

Your suggestion is valid - as HSTS is only delivered over HTTPS - and the upgrade is still required the first time.

See Firesheep for an example of how HTTP can be intercepted - https://en.wikipedia.org/wiki/Firesheep

This will leave your users vulnerable to man-in-the-middle attacks. If I control the router between their computer and the Internet, I can serve back a HTTP page which doesn't redirect, and trick them to enter their password (for example).

HSTS is designed to prevent this.

How can HSTS prevent a man in the middle attack if the server has not even been contacted yet?

It can't, that is what preloading is for. Your browsers comes preloaded with a list of all sites that have requested HSTS preload, so your browser will use HTTPS even on the first visit. This is why preloading on all subdomains is potentially dangerous to use, it could break your site if you don't have HTTPS everywhere.

But even without preloading HSTS will improve security. Yes, the first visit will be susceptible to MITM, but every visit after that is not. This makes it a lot more difficult for an attacker as they must intercept the very first visit for the attack to work.

HSTS preload list is compiled into browser binary: https://chromium.googlesource.com/chromium/src/net/+/master/... https://dxr.mozilla.org/mozilla-central/source/security/mana...

It can only do that if you add it to the preload lists of browsers (which is mentioned in the article).

But even if it is not, it's still helpful for people connecting to your site again.

And because the preload list is hierarchical whole swathes of the Web can be covered with a single entry. .dev is the biggest example, but they can protect all the stack exchanges, all the default blogspot blogs, that sort of thing.

It can't! But after the first time it's been contacted, when you contact it again HSTS will enforce HTTPS (from the client itself - much stronger than a redirect).

> Instead of using HSTS, you can also simply redirect any HTTP request to HTTPS

I think this comment sums up my whole point about how less experienced developers must learn how to use headers.

Like others have commented, HSTS is used to fix potential dangers in forwarding (MITM attacks), it also reduces overhead.

> That way, you are certain that HTTPS is used, even if a browser does not understand HSTS.

If you use HSTS, you should always use a 301 permanent redirect as a fallback method for old browsers and other HTTP clients (like some libCurl implementations).

I think what this comment thread really says is that the burden of fixing mistakes in the web's fundamental design is put on the individual developer and that this is another mistake!

If MITM is a serious issue then it's an extremely bad idea to depend on individual developers of every website out there to mitigate this.

Everything else is just wishful thinking, though. Chrome cannot decide to just deprecate (e.g.) unsafe-inline CSS tags. It would break 90% of websites, and people would move to a different browser to get their websites to work.

Yeah but than you always generate an additional request, with HSTS cached, browser with fetch the https version without an additonal redirect. I wrote a post about it some time ago https://pawelurbanek.com/amp-seo-rating-performance

And break legacy browsers and stupidly implemented corporate proxies and firewalls as well.

Bonus if your URLs get rewritten by something client side which is what HSTS is supposed to protect from and redirect does not.