Blog / Defense-In-Depth / Keep your cloud clean: HSTS preload

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.

Leave a Reply

Your email address will not be published.