87 lines
3.4 KiB
Markdown
87 lines
3.4 KiB
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.
|