b51e62f7 hsts

Keep your cloud clean: HSTS preload


There’s a concept called ‘HTTP Strict Transport Security‘. In a nutshell, if you serve your content over HTTPS, there is no reason for anyone to ever access it downgraded. That downgrade would be the result of some nefarious action.

So to signal this, you place a header on your web site (format as per RFC 6797), something along the lines of:

Strict-Transport-Security "max-age=31530000; includeSubDomains; preload";

OK great. Now when someone first types your site name ‘agilicus.com’, their browser will still open ‘http://www.agilicus.com’. OK, we can solve that, lets add a https-redirect, perhaps using ingress.kubernetes.io/ssl-redirect annotation on our nginx-ingress.

Great. Now when they type ‘http://www.agilicus.com’ if they reach our legitimate site, we will redirect them to our encrypted one, they will see the HSTS and cache it for that max-age time. Solved, right?

We’ve left a case out. What if the very first time they access our site there is something nefarious going on? They never see that HSTS. Hmm. What do to?

Well, let’s add a preload directive (as above), and then register our site here. https://hstspreload.org/?domain=agilicus.ca. This will put our site in the hsts preload list as distributed with the browser. It means that for (many) people that initial check is also secure: their browser will never access us insecure.

Its also in our best interest as a site admin…. That extra round-trip on the first unencrypted session, and bandwidth, is removed. Advanced Security. Efficient. How great is that.