Page MenuHomePhabricator

Fix nits in HTTPS/HSTS configs in externally-hosted fundraising domains
Closed, ResolvedPublic

Description

From https://wikitech.wikimedia.org/wiki/HTTPS/domains, extracting just the Fundraising ones and going into details. Note the only issues of high importance here are the HSTS headers, and frdata's lack of any HTTPS redirect. The rest are mostly nit-picking, but would be nice to have.

[Note this list has been updated over time, removing items that are validated as fixed]

  • http://benefactorevents.wikimedia.org
    • (note: 3rd party hosted)
    • Need HSTS headers (strict-transport-security:max-age=31536000; includeSubDomains; preload)
    • HTTP->HTTPS redirect is 302, should be 301
    • HTTP->HTTPS should be to self first (as in http://benefactorevents -> https://benefactorevents before redirecting to some other name - currently http://benefactorevents redirects immediately to some other name)
  • http://eventdonations.wikimedia.org
    • (note: 3rd party hosted)
    • Need HSTS headers (strict-transport-security:max-age=31536000; includeSubDomains; preload)
    • HTTP->HTTPS redirect is 302, should be 301

Related Objects

StatusAssignedTask
OpenBBlack
ResolvedBBlack
ResolvedArielGlenn
ResolvedChmarkine
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedCCogdill_WMF
DeclinedBBlack
DuplicateBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedJgreen
ResolvedRobH
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack

Event Timeline

BBlack created this task.Jun 6 2016, 10:42 PM
Restricted Application added a project: Operations. · View Herald TranscriptJun 6 2016, 10:42 PM
Restricted Application added subscribers: Zppix, Aklapper. · View Herald Transcript
BBlack updated the task description. (Show Details)Jun 6 2016, 10:43 PM
MoritzMuehlenhoff triaged this task as Normal priority.Jul 6 2016, 8:00 AM
Jgreen updated the task description. (Show Details)Jul 7 2016, 5:47 PM
Jgreen updated the task description. (Show Details)
Jgreen updated the task description. (Show Details)Jul 7 2016, 6:07 PM
Jgreen updated the task description. (Show Details)Jul 7 2016, 6:31 PM
BBlack updated the task description. (Show Details)Jul 11 2016, 3:51 PM

@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)?

@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.

BBlack moved this task from Triage to TLS on the Traffic board.Sep 30 2016, 1:40 PM

What about benefactorevents / eventdonations?

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.

Jgreen claimed this task.Jan 31 2017, 5:42 PM

@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 renamed this task from Fix nits in Fundraising HTTPS/HSTS configs in wikimedia.org domain to Fix nits in HTTPS/HSTS configs in wikimedia.org domain.May 19 2017, 7:10 PM
Jgreen renamed this task from Fix nits in HTTPS/HSTS configs in wikimedia.org domain to Fix nits in HTTPS/HSTS configs in externally-hosted fundraising domains.
Jgreen updated the task description. (Show Details)
Jgreen updated the task description. (Show Details)
Jgreen removed Jgreen as the assignee of this task.May 19 2017, 7:13 PM

This isn't something fr-tech-ops can fix, it's an external site.

Krinkle updated the task description. (Show Details)May 19 2017, 7:19 PM

@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.

@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.

Jgreen updated the task description. (Show Details)
Jgreen removed a subscriber: Jgreen.

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...

Dzahn added a subscriber: Dzahn.Jun 26 2017, 10:20 PM

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?

Jgreen closed this task as Resolved.Jun 28 2017, 12:27 PM
Jgreen claimed this task.

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?

Also deprecating benefactorevents moots T166240, so we can close that at the same time.

Jgreen reopened this task as Open.Jun 28 2017, 12:29 PM

I didn't intentionally close this task...

Jgreen closed this task as Resolved.Jul 10 2017, 1:21 PM

Closing this task because the remaining non-compliant site, benefactorevents.wikimedia.org, has been shut down.

BBlack reopened this task as Open.Jul 10 2017, 3:57 PM

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.

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.

BBlack closed this task as Resolved.Jul 11 2017, 5:10 PM