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

---
layout: post
title: "HSTS"
date: 2019-04-08
comments: true
tags: 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](https://tools.ietf.org/html/rfc6797).

HSTS is easy to enable, and its really cool how much of an impact it
has to improve security.

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
connection.

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](https://hstspreload.org/) 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](https://en.wikipedia.org/wiki/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](https://moxie.org/software/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 clicking 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.