Support HSTS Headers

[gboone]

Currently the site is constrained by it's platform (Cloudfront) and cannot support sending the HTTP Strict Transit Security headers. This means:

1. We are out of full compliance with the Federal HTTPS policy
2. We cannot remain (and indeed have been removed from) the preload list on all major browsers.
3. We cannot guarantee a purely secure connection for our users. HTTP requests are still redirected to HTTPS, but not until after first making a complete HTTP request.

Unfortunately because this is a limitation imposed by Cloudfront, we cannot fix this until Amazon supports it. We should keep an eye on this feature and enable it for at least this site, if not all Federalist sites, when it is supported.

@konklone, please feel free to clarify if I got anything wrong here.

[konklone]

This is all accurate. You're definitely not the only government site in this position (analytics.usa.gov is another).

However, another avenue is to have the base domain preloaded (gsa.gov) for all subdomains, or to move to a separate subdomain on a base domain that is already preloaded (18f.gov). That meets both compliance and security objectives. You could inquire internally with GSA IT about their plans for gsa.gov.

[gemfarmer]

@wslack @jmhooper @konklone

Does this mean that this is taken care of? 😀

https://gsa-tts.slack.com/archives/general-talk/p1485794159004128

[jmhooper]

@gemfarmer: Almost. We still have to deploy production Federalist and migrate sites.

[jmhooper]

@gemfarmer: But, unless I'm mistaken, 18f.gsa.gov should be covered by HSTS preloading? Correct @konklone?

[gboone]

I think we lost that preload when we migrated to Federalist because we could no longer include the header for it.

[gemfarmer]

According to this we are:

https://hstspreload.org/?domain=18f.gsa.gov

I'm not sure how accurate it is though

[jmhooper]

@gboone: Preloading would be handled by the browser / registrar. I'm pretty sure GSA.gov and all subdomains get are preloaded for HSTS. That's not something that's affected be the presence / absence of HTTP headers.

[wslack]

We haven't gotten the greenlight to migrate 18f.gsa.gov onto the new infra yet, but there is a working, tested path now.

[gboone]

@wslack anything I can do to help expedite that, let me know.

[konklone]

According to this we are:

https://hstspreload.org/?domain=18f.gsa.gov

I'm not sure how accurate it is though

It's accurate for Chrome. Chrome doesn't currently validate the header and remove entries. However, Firefox (whose list is based on Chrome's) does validate headers and removes entries which drop the header. Safari and IE/Edge have different policies, which aren't documented and could change any time.

In any case, 18f.gsa.gov is also preloaded as a special exception -- Chrome usually only preloads second-level domains (e.g. gsa.gov), which generally includes all of their subdomains automatically. They added us because I contacted their team directly and asked if they'd do it, since it would be the first preloaded .gov URL of any sort. It was nice of them to do so, but in general preloading is something that gets applied to entire registerable zones.

[gboone]

To paraphrase, @konklone, in order to get Firefox and get preloaded the normal way, we'd have to have GSA send Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. Correct?

[konklone]

Yes, gsa.gov would need to send that header (the max-age can be anything above 1 years' worth of seconds) to be preloaded the normal way.

Also, Firefox might pick us back up if we start sending the header again, since we're still in Chrome's list.

[gemfarmer]

@wslack @jmhooper is this issue solved with the new GovCloud migration?

cc @coreycaitlin @gboone

[jmhooper]

@gemfarmer: Yep :+1:

[gemfarmer]

Thanks again!