blogng/blog/2019-04-08-notes-on-hsts.markdown

layout	title	date	comments	tags
post	HSTS	2019-04-08	true	hsts, security, privacy

HTTP Strict Transport Secrity is a mechanism for sites to signal that they would only be serving a secure transport (read: TLS) to serve content from these domains. HSTS is defined in RFC6797. HSTS is really cool considering how easy is to enable it!

So how does it work? The secure version of the site sends an extra HTTP header

strict-transport-security: Strict-Transport-Security: max-age=31557600;

To an HSTS aware client (i.e all mordern browsers) this means

I swear that I will serve content on secure transport for atleast next 31557600 seconds (1 year)

client can now cache this information, and if you ever get the non-secure version of the site - know that someones tampering with the site.

But max age is only one of the directive, there are more.

1. includeSubdomains directive: Tells your browser that apply the same rule to all subdomains of the current domain.
2. preload directive: Tells the client they can preload these rules, doesn't do much on its own - but with this you can apply to be included in HSTS preload list. If you are on this list, all your users will have these rules shipped them when they install their browser, so no need to get this info from their first visit.

Why should you do this?

HSTS helps enforce HTTPS much better for a user, thus helping us avoid non-secure transport attacks much better.

1. Passive network attackers

Threats from people sniffing your network passivly, like someone else on a public coffee shop wifi you are currently using. The best attack I can think of is FireSheep. Firesheep sniffs for session information send over cleartext in a public network, and uses that to impersonate you. Firesheep is mitigated by never sending session tokens in a clear transport. HSTS helps browsers to force the transport to be secure and fail if someone is trying to downgrade the connection to mount a firesheep style attach.

2. Active network attackers

Threats from people inside the network, someone who has access to how you get on the internet (someone who got access to your ISP or the wifi router etc). Best example is sslstrip. sslstrip fools the client into beliving a secure transport does not exist for a particular domain, thus forcing it to send sensitve data over cleartext. HSTS will be able to detect this and prevent connecting to the site.

3. Deployment and management errors

Deploying https is getting easier everyday, but still quite tricky to get right if you are deploying a complex system. HSTS helps prevent management errors where one might have accidently exposed some services (I'm looking at you legacy cruft!) on a subdomain, or embedded in a https site (so called mixed content errors)

4. No click through errors. HSTS also helps mitigate user errors, in case of breakage hsts spec forces client to not allow users to override their behaviour by clicking through.

A note of caution

HSTS is pretty unforgiving (for a good reason) in cases of TLS screwups. Also, its really hard to get out of preload lists. Make sure your https deployment is rock stable pushing out HSTS, start with a small time delta, and keep increasing after careful testing.