How does HSTS stop MitM attacks?

The HSTS header stops MitM attacks by instructing the browser to always send HTTPS (as opposed to HTTP) request to the domain until the policy expires. So a browser that respects the header would send a request to https://example.com even if the user clicked a link to http://example.com.

The logic behind HSTS has not changed since it was defined in an RFC in 2012. What has changed is that today almost all browsers implement it. Remember that it is the browser that enforce this policy! Can I Use reports browsers supporting it from the following versions:

• Internet Explorer 11 (2015)
• Firefox 4 (2011)
• Chrome 3 (2010, possibly also supported earlier)
• Safari 7 (2013)

(How Firefox and Chrome managed to support HSTS before the RFC was out is a mystery to me.)

So people using browsers older than that will not be protected even if the header is set. That might account for why you have the impression that setting the HSTS header did not use to help against SSLStrip earlier.

Another reason for HSTS not helping can be that the user has never visit the page before the attack. If the browser has never seen the header it can not enforce it. This can be solved with preloading.

SSLStrip worked rewriting https requests to plain http, removing the protection and allowing both eavesdropping and modification.

A server with HSTS protection will set a header on a HTTPS request asking the browser to only contact that server using HTTPS:

Strict-Transport-Security: max-age=31536000

In this case, for one year the browser will only connect to the server on HTTPS, and rewrite all links to be HTTPS (an inverted SSLStrip).

But there's a caveat: the client must have accessed the server using HTTPS at least once. If the client only connects via HTTP, MiTM still can occur, all requests can be altered and any HTTPS link or redirection can be changed back to HTTP. But as soon as the client access the server using HTTPS, the HSTS cookie is set and SSLStrip MiTM attacks are not possible anymore.