From ead1e130064a922d707dc36cc9972819631e9f61 Mon Sep 17 00:00:00 2001 From: Dhananjay Balan Date: Thu, 11 Apr 2019 11:03:21 +0200 Subject: [PATCH] Rewrote HSTS post --- blog/2019-04-08-notes-on-hsts.markdown | 74 ++++++++++++++++++++------ 1 file changed, 57 insertions(+), 17 deletions(-) diff --git a/blog/2019-04-08-notes-on-hsts.markdown b/blog/2019-04-08-notes-on-hsts.markdown index c2cb094..55ad4c5 100644 --- a/blog/2019-04-08-notes-on-hsts.markdown +++ b/blog/2019-04-08-notes-on-hsts.markdown @@ -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.