Page MenuHomePhabricator

Inconsistent enforcement of HTTPS in discuss-space.wmflabs.org
Closed, ResolvedPublic

Description

This is strange:

Meanwhile

As far as I am aware, we applied to discuss-space the same "messy hack" that discourse-mediawiki has:

/etc/nginx/conf.d/discourse.conf 

#Messy hack to force SSL on only the hostname, not IPs so ELB and Icinga work.
  set $use_https NO;
  if ($host ~* 'discourse-mediawiki.wmflabs.org') {
    set $use_https A;
  }
  if ($http_x_forwarded_proto != 'https') {
    set $use_https "${use_https}B";
  }
  if ($use_https = AB) {
    rewrite ^ https://$host$request_uri? permanent;
  }

Halp!

Related: T227019: Redirect all space.wmflabs.org traffic to HTTPS

Event Timeline

Qgil created this task.Jul 16 2019, 6:59 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 16 2019, 6:59 AM
Qgil triaged this task as Medium priority.Jul 16 2019, 7:00 AM
Qgil added a subscriber: Tgr.
Qgil updated the task description. (Show Details)Jul 16 2019, 7:47 AM
Stryn added a subscriber: Stryn.EditedJul 30 2019, 10:14 AM

When searching on Google "space wmflabs" the first result is http://discuss-space.wmflabs.org/ (not https), so the content on site won't appear at all on Firefox.

It redirects just fine for me in Firefox 68.

elappen-WMF added a subscriber: elappen-WMF.EditedAug 17 2019, 1:11 PM

The redirect is currently not working in Chrome, Safari or Firefox. Only the navigation bar is visible.

Firefox error:

Content Security Policy: The page’s settings blocked the loading of a resource at http://discuss-space.wmflabs.org/assets/preload-application-…b480941aaac91f9e7fa7f77496323ae056aaa4158822dea35de319c01.js (“script-src”).

@JHedden @bd808 You helped fixing T227019: Redirect all space.wmflabs.org traffic to HTTPS. Do you have any idea what might be going on here?

InsaneHacker added a subscriber: InsaneHacker.EditedAug 23 2019, 11:16 AM

I've been able to replicate this reliably more than 3 times now: When I access the discussion board directly via the URL discuss-space.wmflabs.org, I get an unsecure HTTP connection and most the page contents don't show up. If I go to the front page, space.wmflabs.org, and then click on the Discuss-link, I get an HTTPS connection.

EDIT: Just realized this is because the menu link on the front page contains https://-links, and so the above might not be new information. What is interesting is that when I access the site using the described insecure method, clicking any menu link other than the front page and Blog-links, the insecure connection remains. Presumably that's because the other menu links are still within the discuss-space.

In a chrome incognito session without HTTPS-Everywhere, I can reproduce http://discuss-space.wmflabs.org/ serving a 200 response rather than the hoped for 301 Redirect response. Seems pretty obviously to be misconfiguration at the Nginx level.

#Messy hack to force SSL on only the hostname, not IPs so ELB and Icinga work.
  set $use_https NO;
 if ($host ~* 'discourse-mediawiki.wmflabs.org') {
   set $use_https A;
 }
 if ($http_x_forwarded_proto != 'https') {
   set $use_https "${use_https}B";
 }
 if ($use_https = AB) {
   rewrite ^ https://$host$request_uri? permanent;
 }

Is this copy-and-pasted from somewhere else? If this is just a "normal" backend instance behind the shared TLS reverse proxy provided for Cloud VPS tenants, I would think that this would work:

if ($http_x_forwarded_proto != 'https') {
    return 301 https://$host$request_uri;
}
Qgil added a comment.Aug 26 2019, 10:27 AM

We have copied what seems to work at discourse-mediawiki.wmflabs.org, which seems to have been copied from somewhere else...

For how this code landed in discourse-mediawiki, see T180854#3880870 and comments below.

Tgr added a comment.Aug 27 2019, 6:56 PM

I tried to check the config but I get this:

tgr@discuss-space:/var/discourse$ sudo ./launcher enter app
You have less than 5GB of free space on the disk where /var/lib/docker is located. You will need more space to continue
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda3        19G   14G  4.3G  76% /

Would you like to attempt to recover space by cleaning docker images and containers in the system?(y/N)

(Why Discourse insists on 5G free space to give me a shell is beyond me.)
So that will have to be dealt with at some point.

Qgil added a comment.Aug 28 2019, 5:51 AM

I ran ./launcher cleanup resulting in

Total reclaimed space: 5.77GB

./launcher enter app works now.

Qgil added a comment.Oct 2 2019, 10:21 AM

Mmm I feel really stupid now.

After ./launcher enter app I go to /etc/nginx/conf.d and then vim discourse.conf (argh, where is my dear nano!?)

My first surprise is that the "messy hack" is not there. I swear I had added it. I check the same file in discourse-mw. The messy hack is there.

Alright. Nevermind. I add the configuration that Bryan shared above

if ($http_x_forwarded_proto != 'https') {
    return 301 https://$host$request_uri;
}

I exit with :wq. I access the file again, my change is there. Good.

I exit the app and run ./launcher rebuild app. HTTPS still isn't forced. I go check discourse.conf again. MY CHANGES ARE GONE!

So I feel very stupid because there is something very basic that I seem to be missing here, and because of this we probably have been more than three months with HTTPS working only half way.

Halp please!

Qgil claimed this task.Oct 2 2019, 10:22 AM
Qgil raised the priority of this task from Medium to High.
Qgil edited projects, added Space (Oct-Dec-2019); removed Space.
Qgil moved this task from Backlog to Started on the Space (Oct-Dec-2019) board.
Tgr added a comment.Oct 2 2019, 12:28 PM

Well, rebuild destroys and recreates the Docker container so it doesn't seem that surprising. Probably templates would be the right way to do it (or just don't rebuild the container often :).

Qgil added a comment.Oct 2 2019, 7:44 PM

Hm. But... I guess we have rebuilt discourse-mediawiki since we set it up almost two years ago, and the messy hack is still there. In act, installing a new plugin requires to rebuild the app. Isn't there a way to make this change persistent?

Qgil added a comment.Oct 3 2019, 7:46 AM

(OK, I replied too fast yesterday. Templates. I'll try today.)

Qgil closed this task as Resolved.Oct 3 2019, 8:44 PM

Alright.

discourse-mw has a file /templates/web.toolforge.yml that discuss-space misses, and the messy hack is there. I have created an equivalent file at discuss-space with the shorter and cleaner configuration shared by Bryan above, I have rebuilt discuss-space and... HTTPS enforcement seems to work!

I have tested with Firefox, and http redirects to https.

Also, a couple of other tests:

These things were broken because of http/https inconsistencies.

Qgil moved this task from Started to Evaluated on the Space (Oct-Dec-2019) board.Oct 28 2019, 7:56 AM