Sort HTTPS and make it available to everyone
Open, HighPublic

Description

HTTPS has been one of those things on just about everyone's wishlist for a long time. We've all got different priorities for this, but I'd say it should now be fairly high - particularly when we're talking about logging in and private wikis.

We missed the big craze over state-sanctioned surveillance, however, we should still be working pretty actively to sort this.

In the past, our main blocker has been that our URL scheme has made it difficult to cover the entire farm in our certificate. Our wildcard is *.shoutwiki.com which covers a large number of our wikis, but not those that use a language prefix in their URL (such as de.foobar.shoutwiki.com) We can't get a double wildcard (*.*.shoutwiki.com)

We need to have a discussion about how we're going to finally solve this problem.

Previous solutions suggested are:

  • Remove all sub-subdomains and keep the current wildcard.
  • Change the pattern to wiki.language.shoutwiki.com and use SAN or additional certificates (now a lot easier thanks to Let's Encrypt) to cover this pattern.
  • Don't implement HTTPS.
lewiscawte triaged this task as "High" priority.

I'm open to other suggestions - as changing URLs isn't the most fun thing to do...

But my opinion would be to remove all subsub-domains. I do like the idea of having language based subdomains, but it seems to make life a lot harder.

This should be a community discussion...

jack added a comment.Oct 31 2016, 6:01 PM

I'll throw in my favorite solution, which Skizzerz proposed the last time I spoke to him about this: Let's Encrypt SSL certificates for <lang code>.*.shoutwiki.com, i.e. fi.*.shoutwiki.com (possibly relevant: this StackOverflow question). Looking at /trunk/languages/i18n/, there are currently 371 files in there so it would mean about the same amount of SSL certificates, which admittedly is somewhat of an ops nightmare, but the renewal of Let's Encrypt certificates can be automated and I'm sure someone already made a script for that.
I would imagine that this is a solution that'll be painful to implement initially but which wouldn't need too much maintenance after that and it would allow us to keep the current URL structure.

If, for some reason, it's outright impossible to keep the current URLs, I guess my preference would be topic.shoutwiki.com/lang/Page_name, i.e. 24.shoutwiki.com/fi/Jack_Bauer for the page currently located at http://fi.24.shoutwiki.com/wiki/Jack_Bauer , but before going down this route I'd really want us to explore all the possibilities that allow us to keep the current URLs, because, to quote Tim Berners-Lee, "good URIs don't change". (Unlike a lot of sites, I think we'd be able to implement proper redirects, but let's be real, it'd still be pretty obnoxious, to say the very least.)

In T131#1828, @jack wrote:

I'll throw in my favorite solution, which Skizzerz proposed the last time I spoke to him about this: Let's Encrypt SSL certificates for <lang code>.*.shoutwiki.com, i.e. fi.*.shoutwiki.com (possibly relevant: this StackOverflow question). Looking at /trunk/languages/i18n/, there are currently 371 files in there so it would mean about the same amount of SSL certificates, which admittedly is somewhat of an ops nightmare, but the renewal of Let's Encrypt certificates can be automated and I'm sure someone already made a script for that.
I would imagine that this is a solution that'll be painful to implement initially but which wouldn't need too much maintenance after that and it would allow us to keep the current URL structure.

Let's Encrypt doesn't do wildcards currently. Additionally, one of the major problems we had with switching to Nginx was that our code (somewhere in LocalSettings) meant that the first domain in Nginx's server_name had to be shoutwiki.com, then followed by the wildcard. Multiple shoutwiki.com's are, from memory, going to conflict. Nginx only allows one certificate per server block, so I don't think this solution is physically possible. You're also right; it's an ops nightmare.

Although thinking about it... we might be able to do it at terminator level, assuming we had all the right wildcards. Not something I'd imagine is ever normally done, certainly not easy to do, but may just be technically feasible. Although our terminator still needs a lot of work.

If, for some reason, it's outright impossible to keep the current URLs, I guess my preference would be topic.shoutwiki.com/lang/Page_name, i.e. 24.shoutwiki.com/fi/Jack_Bauer for the page currently located at http://fi.24.shoutwiki.com/wiki/Jack_Bauer , but before going down this route I'd really want us to explore all the possibilities that allow us to keep the current URLs, because, to quote Tim Berners-Lee, "good URIs don't change". (Unlike a lot of sites, I think we'd be able to implement proper redirects, but let's be real, it'd still be pretty obnoxious, to say the very least.)

This makes short URL a nightmare. You know, I'm not sure how we'd even do this from an HTTPd point of view... it'd be easier with a server block for each language, but as noted in the previous solution, I don't think that's possible.