Rewrote HSTS post
This commit is contained in:
parent
99940dc316
commit
ead1e13006
@ -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 doesnot exist for a particular
|
||||
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.
|
||||
|
Loading…
Reference in New Issue
Block a user