https://cpdl.org

[AlexMyltsev]

Hi,

it seems that CPDL does not support HTTPS, even for the contributor wiki. An Apache webserver is listening on cpdl.org:443, but it just serves an error page. So contributors send their passwords over HTTP, like in 2005. It pains me to see this .

It should be pretty easy to get a free TLS certificate from letsencrypt.org and use it on cpdl.org, even if only for the contributor wiki. This should not take the administrator more than 20 minutes, and I'd volunteer to assist in the process (I have configured nginx to do this a number of times, it is straightforward).

We don't have to redirect people from HTTP to HTTPS at first, for fear of increased server load; the HTTPS option will just be there for the few security-sensitive contributors . Later, if the server load is acceptable, the login links can be changed to let everyone be more secure.

[vaarky]

We're very sorry we overlooked replying on this. We have been and are continuing to work on this.

[AlexMyltsev]

We have been and are continuing to work on this.

As I mentioned back in 2016, setting up HTTPS is a matter of half an hour.

I can only repeat my offer: whenever an administrator of CPDL can spare an hour of his time, we can walk through the process together, step by step, and just make HTTPS work. My Telegram username is myltsev, my email is a.myltsev@gmail.com. Non-working HTTPS is a shame in 2018, and I hope together we can overcome this deplorable situation.

[choralia]

As I mentioned back in 2016, setting up HTTPS is a matter of half an hour.

No, it's much more than that: traffic is distributed to multiple servers that use different technologies, and users should be transparently handled by all servers. Installing a certificate on a server is easy, however configuring the whole system to work consistently is not completely obvious. Our multi-server architecture may require some modification to work under https. We also have to modify some custom extensions, which were originally conceived to work under http only.

Preliminary tests have also revealed that the MediaWiki software version currently used (1.29) has a strange behavior related to the management of login/session cookies under https. The session storage has been changed since previous versions, and sometimes the mechanism to prevent session hijacking is unexpectedly triggered. This is very nasty as users cannot login then. This problem may be somehow emphasized by our multi-server architecture, so we have to be very careful before deploying https. Extensive testing is required.

Meanwhile, MediaWiki version 1.30 was released. Updating from version 1.29 to version 1.30 will require to perform the complete set of non-regression tests, too. So, it makes sense to perform the two activities (upgrade to version 1.30 and modifications/tests for https) altogether. We generally perform Mediawiki version upgrades during off-peak traffic periods (Christmas, Easter, or Summer), to minimize the impact of possible issues. So, the next reasonable target is Easter time. I'm afraid that you have to patient, and accept "this deplorable situation" a little bit longer...

Max

[choralia]

the next reasonable target is Easter time

Unfortunately there was no time enough to implement and test the upgrade to MediaWiki version 1.30. However, it was possible to apply the modifications required for running https on the multi-server architecture.

SLL certificates are now installed on all servers, which are enabled both for http and https. Unless the user manually enters http or https on a given server, logged-in users will be normally served in https by the contributor wiki (www), while anonymous users will be normally served in http by the visitor wikis (www0, www1, www2 and www3). This server hosting the forums is also enabled for https (I'm using https right now).

It is possible that some internal links are hard-coded in http, and therefore a "mixed content" warning is displayed when running in https. For example, I've recently found that the Llypond icon had a hard-coded http link inside, so I had to correct it in order to get rid of the "mixed content" warning. Similar tweaks may be occasionally required until all http hard-coded links are fixed.

Max

[vaarky]

At some point, can we search programmatically for pages with hard-coded http:// links and auto-replace them?

[Claude_T]

I removed/replaced all (29) occurrences of 'http://www.cpdl' found through 'Special:Replace text' page, on our pages.
Don't know if some other remain, more deeply hidden.