Closed pburkholder closed 4 years ago
@pburkholder I'm a bit confused: is this a cg-site
fix or a fix in Federalist that is broader, that cg-site
and all other Federalist sites would then benefit from? Based on the implementation notes from Amir, it looks like this is already done and is in the master
branch.
Is it just not pushed live yet, or am I missing something else all together (which is highly likely in this case)?
D'oh I think I answered my own question - there's no entry for cloud.gov
in this template redirect file yet, is there? I don't see one, is it just a matter of adding one in?
cloud.gov was never a Pages site though, so I wonder if this would still work or if there's something else that needs to be done.
my understand is that we need to both a) move the cloud.gov site to www.cloud.gov and b) add cloud.gov to the redirect template. Whether this can be done without any downtime is 🤷.
Thanks for asking, I should have made that clearer in the issue.
No worries at all, thank you for the clarification, @pburkholder!
I pinged Amir for help to pick this up and work through it; will hopefully have it taken care of early next week!
I have time scheduled with Amir on Wednesday afternoon (4 PM ET). The work should take us about 30 minutes or so, but it'll take a bit of time for DNS to fully update.
Furthermore, the www.cloud.gov
resolution should continue to work fine throughout this, but cloud.gov
will be down for a bit. What should we do in terms of notifications to the site? So far I have the following:
Perhaps also send a quick message out via our customer list, if we don't feel StatusPage will reach enough?
~Draft~ Message to send out via StatusPage. ~Please provide feedback to help improve!~
The cloud.gov domain name will be undergoing maintenance to fix an issue we've identified with its HSTS support
. This will result in the cloud.gov website being unavailable for a short period of time at the https://cloud.gov/
domain (without www
in the front) - https://www.cloud.gov/
(with the www
in the front) should continue to work during this maintenance. The maintenance window is scheduled for Wednesday, 4/29/2020, from 4 PM ET to 5 PM ET.
The cloud.gov website recently switched to being hosted and maintained on Federalist, and the HSTS header configuration is not fully HSTS preload-compliant. This is required configuration per our public documentation and our SSP (SC-20(b) and other SC controls), so we are making sure that the configuration is put back in place. This change will require DNS updates for the cloud.gov
domain, which may take some time until all the redirects work.
You should still be able to visit the cloud.gov website at https://www.cloud.gov during the maintenance window if you need to view the website. The update itself will take a short amount of time, but the DNS updates for the cloud.gov
domain may take up to 72 hours to take effect.
I don't have access to StatusPage so I can't help with posting the message.
David Corwin brought up an excellent point:
Would y’all mind explaining:
The cloud.gov website recently switched to being hosted and maintained on Federalist, and the HSTS header configuration is not fully HSTS preload-compliant
Many folks who receive the status update may also be Federalist users and I’m concerned about what this implies about Federalist sites.
David's right, we don't want to imply there's something wrong with Federalist. Here is my proposed update:
For users of both Federalist and cloud.gov, we want to explicitly note that the cloud.gov website's HSTS header not being preload-compliant is not an issue with Federalist itself. The issue was caused by an error in additional customization for the cloud.gov website itself, not by the Federalist deployment.
Federalist and cloud.gov themselves are functioning properly and HSTS configuration is automatically taken care of under normal circumstances for sites hosted by Federalist. We apologize for any confusion this may have caused.
@eddietejeda and @pburkholder, how does this look to you? A big thank you to David for bringing this up and helping with the wordsmithing!
We ran into a snag when trying to start working through the steps to perform this and had to regroup as a team to come up with an alternate solution.
We appear to be unblocked! A HUGE thank you to @bengerman13, @spgreenberg, and Amir for all of the help talking through this!
Additional updates: Amir and David are going to adjust the federalist-proxy
app directly to account for the cloud.gov
domain and make sure it's headers are set properly to account for this. Provided this works, there will not be any further work on our part.
Added a PR for HSTS header update. https://github.com/18F/federalist-proxy/pull/57
Adding @apburnes as an assignee to this given his work here: https://github.com/18F/federalist-proxy/pull/57
Thank you, @apburnes, and please let me know how I can help! I David is reviewing your PR.
David and Amir are going to validate and test these changes one more time. This should be going out tomorrow (5/5/2020).
This PR fixed headers https://github.com/18F/federalist-proxy/pull/58
Let's close this. Monitoring any drift in HSTS will be covered in this ticket: https://github.com/cloud-gov/cg-compliance/issues/198
Done and done!
Both our public documentation, https://cloud.gov/docs/compliance/domain-standards/, and our SSP (SC-20(b) and other SC controls) refer to HSTS as a rationale for not needing DNSSEC.
Our move to Federalist removed the header
includeSubDomains
from https://cloud.gov.This means we're at risk of having
cloud.gov
removed from Chrome's preloaded list. https://hstspreload.org/?domain=cloud.gov :Implementation:
Per suggestion from Amir in Slack: https://gsa-tts.slack.com/archives/C1NUUGTT5/p1585749175038700?thread_ts=1585693357.037800&cid=C1NUUGTT5