@Jgreen thanks for working on this! I've re-audited all the Fundraising wikimedia.org hostnames, updated https://wikitech.wikimedia.org/wiki/HTTPS/domains , and updated the description of the above. Three of the hosts that were marked [FIXED] are removed (audit confirms no issues). I took the [FIXED} off of civicrm, as it's still not emitting HSTS headers on basic checks. It may be that they're configured in software for successful authenticated page fetches, just not unauthenticated checks (e.g. with basic curl)?

In T137161#2447794, @BBlack wrote:

@Jgreen thanks for working on this! I've re-audited all the Fundraising wikimedia.org hostnames, updated https://wikitech.wikimedia.org/wiki/HTTPS/domains , and updated the description of the above. Three of the hosts that were marked [FIXED] are removed (audit confirms no issues). I took the [FIXED} off of civicrm, as it's still not emitting HSTS headers on basic checks. It may be that they're configured in software for successful authenticated page fetches, just not unauthenticated checks (e.g. with basic curl)?

Looked into this a bit this AM and it turns out this isn't specific to civicrm.wm.o but happens wherever the tested page is a 404 and we're running the Precise stock nginx. With later nginx versions tacking 'always' onto the header declaration fixes it, I'm not sure yet if there's a workaround for the older nginx version. However, I believe we ~are~ serving the HSTS header for 200s etc.

What about benefactorevents / eventdonations?

In T137161#2972789, @BBlack wrote:

What about benefactorevents / eventdonations?

These are hosted externally by our contractor, so it will take some research to figure out what degree of control we have over HSTS headers etc. I will look into it.

@CCogdill_WMF we'd like to make some adjustments to the benefactorevents and eventdonations webserver config to bring them inline with WMF SSL standards. The specific changes are in the task description above. Can you help and/or connect me with the right folks at Trilogy?

Thanks for the ping @Jgreen, we're looking at it.

@Jgreen - re: civicrm, it needs to emit the HSTS header on all HTTPS responses.

$ curl -v https://civicrm.wikimedia.org/
[...]
< HTTP/1.1 403 Forbidden
< Server: nginx
< Date: Sat, 20 May 2017 03:19:04 GMT
< Content-Type: text/plain
< Content-Length: 71
< Connection: keep-alive
< 
* Curl_http_done: called premature == 0
* Connection #0 to host civicrm.wikimedia.org left intact
An authorized SSL client certificate is required to access this server.

In T137161#3277960, @BBlack wrote:

@Jgreen - re: civicrm, it needs to emit the HSTS header on all HTTPS responses.

$ curl -v https://civicrm.wikimedia.org/
[...]
< HTTP/1.1 403 Forbidden
< Server: nginx
< Date: Sat, 20 May 2017 03:19:04 GMT
< Content-Type: text/plain
< Content-Length: 71
< Connection: keep-alive
< 
* Curl_http_done: called premature == 0
* Connection #0 to host civicrm.wikimedia.org left intact
An authorized SSL client certificate is required to access this server.

Ah right, now that we're on Jessie getting nginx to add the header for non-200 responses finally becomes feasible. However it requires switching to the backports version of nginx (which depends on the newer backports version of libssl), so it will take some time to test it.

@BBlack ok I upgraded nginx and *ssl, and civicrm and the other frack-hosted sites should be fixed to include the HSTS header with 3xx's:

jgreen@weasel:~> curl -v https://civicrm.wikimedia.org/
[...]
< HTTP/1.1 403 Forbidden
< Server: nginx
< Date: Tue, 23 May 2017 19:28:08 GMT
< Content-Type: text/plain
< Content-Length: 71
< Connection: keep-alive
< Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
<

• Connection #0 to host civicrm.wikimedia.org left intact

An authorized SSL client certificate is required to access this server.

Major Gifts is discontinuing the events integration we had in place through these sites. The contract ends at the end of the month, so I'm pretty sure the pages will go down at that time. Major Gifts may use these subdomains with a new integration later, but can we close this task since these pages won't be in use?

Yeah we can close this task if the sites are gone. We'll want to remove the current IP address mapping for these hostnames from our DNS when this happens (or now, if they're already no longer in use), to complete the removal of the concern. Is it just benefactorevents.wikimedia.org and eventdonations.wikimedia.org that are going away, or also others like benefactors.wikimedia.org?

As far as I know, it is just those first two subdomains you listed. I'm not
sure benefactors.wikimedia.org goes anywhere, anyway...

benefactors.wikimedia.org may not be used for HTTP(S) but it is apparently used for email?

T130937

https://phabricator.wikimedia.org/rODNSc6dc7dcb64c4f6e641d8d3e1f9e2d32d5a489a09

Oh, I see. I'm not entirely sure about this.

@DKaufman I'm trying to identify which domains are getting phased out with the Trilogy system. We use benefactors.wikimedia.org to send receipt emails to donors through Trilogy's system. Do you know -- is Stripe set up to do the same thing with our domain? Can we remove the DNS for all of these hostnames?
benefactors.wikimedia.org
benefactorevents.wikimedia.org
eventdonations.wikimedia.org

Let's not forget to actually revoke those certificates too. We're getting a little off-topic here though, so perhaps @Jgreen / @CCogdill_WMF / @DKaufman, once you know all the details around this, can you open a task that will track this deprecation and all the steps involved?

In T137161#3421335, @BBlack wrote:

All of these hostnames are still in DNS AFAICS:

benefactors.wikimedia.org
benefactorevents.wikimedia.org
eventdonations.wikimedia.org

We need to remove all of these records before we resolve this. As Faidon mentioned, we should also revoke the certificates that were issued for these if they're still valid (preferably after the DNS changes, I think). Or we can make a separate shutdown task that blocks this, whatever works.

benefactorevents: I linked the existing task for cert revocation as a subtask.

eventdonations: Points to a dead AWS site. I'm researching what it site is/was, and will link cleanup subtasks once I get clarification.

benefactors: Fundraising has used this domain for mail so there's incoming exim config and SPF/DKIM policies allowing outbound mail from Zendesk. This is not an external web site (A record points to our text-lb's) so I don't know why it's on this task.

benefactors - It wasn't originally part of the original task here, we've just been questioning whether it's also being removed at the same time, since it seems related.