# Keep your cloud clean: HSTS preload

- Link: https://www.agilicus.com/keep-your-cloud-clean-hsts-preload/
- Published: 2019-04-03T18:49:38+00:00
- Author: Don Bowman

There’s a concept called ‘[HTTP Strict Transport Security](https://en.wikipedia.org/wiki/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](https://tools.ietf.org/html/rfc6797)),
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](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.