Trellis: Consider disabling HSTS by default

[retlehs]

moving our internal discussion from this weekend onto here so we don't forget about it

Let’s say you have HSTS enabled. At some point something (pick a scary thing…any scary thing will do) goes wrong with your SSL configuration and your server is unable to serve a secure request. Your server cannot fulfill the secure request, but the browser (because of the HSTS header) cannot request anything that is insecure. You’re at an impasse and your visitor cannot see the content or asset in question. This remains the case until either your SSL configuration is restored or the HSTS header expires. Now imagine you’re running a large site with multiple teams and lots of moving parts and you see just how scary this issue could be.

Because of this risk, HSTS has to be an option that a user must specify in Let’s Encrypt—despite its importance.

• [x] I've read the guidelines for Contributing to Roots Projects

[tmdk]

At the very least, consider turning off includeSubdomains as a default. I've been bitten by this (external service hosted on a subdomain that does not support https)

[markjaquith]

Strongly agree with disabling HSTS by default. The cost of a mistake is too high.

[retlehs]

yeah we should do this... and update the docs here: https://roots.io/docs/trellis/master/mail/#development

not sure where we've left off on this, are there any reasons not do this - @swalkinshaw?

[swalkinshaw]

Unfortunately one issue with switching the default is it will mean someone loses their HSTS setting without realizing it. Of course we'll mark the change as breaking and communicate what they need to do... but still. Just a minor thing to consider.

The cost of a mistake is too high.

Is this true? If max-age is set to 0 then the problem is fixed. So consider the trade offs of making a mistake, then fixing it, vs all the people that won't have HSTS enabled at all after this.

I'm not entirely against this, I just don't know it's as clear cut as we think?