HSTS directs the browser to use HTTPS for certain domains (optionally subdomains). This mitigates some MitM attacks by upgrading HTTP connections to HTTPS.
HSTS Preloading
The native implementation of HSTS communicates the HSTS policy to the browser via an HTTP response header Strict-Transport-Security: max-age=31536000; includeSubDomains. HSTS requires a user to visit a website once before HSTS protection is cached.
But what if HTTP is used on the first visit or a user clears their cache frequently? An attacker can still redirect the user to a malicious site by altering the response.
Enter HSTS Preloading. It ensures common domains are configured with HSTS without requiring an initial vulnerable visit.
Another method to upgrade HTTP requests is to enforce HTTPS only connections in your browser.
HSTS Preloading Implementation - DevTools
Let’s see how HSTS Preloading works in practice.
- Visiting
http://www.google.com/
The browser appears to send a request to an internal service to upgrade the HTTP request.
No HTTP requests hit the network interface. Confirming this is internal to the browser.
- Visiting
http://google.com/
http://google.com/ redirects to http://www.google.com The request and redirect response hit the network interface in the Wireshark capture below.
Similar to above, http://www.google.com/ is upgraded to https://www.google.com/ internally within the browser.
If you need to visit Google manually, you should probably type
www.google.comrather thangoogle.com. Address bar searches use HTTPS by default.
Conclusion
HSTS is a powerful mechanism for protecting users against MitM attacks such as SSL Stripping or Session Hijacking.
But HSTS isn’t a simple on/off switch on the client side. Many vulnerable combinations of settings exist, depending on the server and user input.