dbalan/blogng
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Rewrote HSTS post

Browse Source
This commit is contained in:
Dhananjay Balan 2019-04-11 11:03:21 +02:00
parent 99940dc316
commit ead1e13006
1 changed files with 57 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

72
blog/2019-04-08-notes-on-hsts.markdown
View File

@ -1,42 +1,82 @@
---
layout: post
title: "Notes on HSTS"
title: "HSTS"
date: 2019-04-08
comments: true
tags: hsts, security, privacy
---
I was recently looking into enabling HSTS sitewide on a medium sized
site, and went through a reading spree of specifications
involved. These are my notes.
## What is HSTS
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. It is defined in
[RFC6797](https://tools.ietf.org/html/rfc6797).
content from these domains. HSTS is defined in
[RFC6797](https://tools.ietf.org/html/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](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.
### Threats mitigated
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 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.
[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). An attack example is
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 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.