We recently enabled protocol-relative URLs on all Wikimedia Foundation wikis. That change was in preparation for this change: we’ve just enabled native HTTPS support on all wikis.
What does this mean?
This means that you can now visit sites using the HTTPS protocol; for instance, if you wish to visit the English Wikipedia, you can go to: https://en.wikipedia.org. This allows you to visit our sites without having your browsing habits tracked, and you can log in without having your password or user session data stolen.
Didn’t we already have secure.wikimedia.org?
Yes. However, there were a number of cons associated with secure.wikimedia.org:
- The URLs for secure were different than the URLs for the projects; Commons was at: https://secure.wikimedia.org/wikipedia/commons/wiki/Main_Page. Unless you followed a link there or were using the HTTPS Everywhere browser extension it would be difficult to know how to get there.
- We have a bunch of web server configuration hacks to make secure work properly.
- Secure isn’t enabled for everything, thanks to the difficult configuration hacks needed to add new sites.
- Secure isn’t scalable. Secure bypasses most of our caching layers, and is difficult to run on more than a single server.
- Secure isn’t actually secure. It always has mixed-content due to the above issues and because upload.wikimedia.org didn’t have HTTPS support.
How is this better than secure.wikimedia.org?
- The URLs are exactly the same, just the protocol is different.
- The SSL servers only do SSL termination, and they do it before our caching layers. This means that this is a transparent addition to our architecture. When we scale other pieces of our architecture, this will scale with it.
What will happen to secure.wikimedia.org?
But, I still get mixed-content warnings!
Some links are bringing me back to HTTP mode
All of the links in our content have changed from being protocol-specific to protocol-relative. This content is cached in our squid layer, and in our parser cache. We don’t wish to clear our entire cache immediately to fix this, as it would cause severe performance issues. Instead we will either clear the cache slowly over time, or we’ll let it clear naturally. This will take at most a month.
How will this affect HTTPS Everywhere?
A lot of us use HTTPS Everywhere too, so we definitely want this updated as well. We’ve been working closely with the EFF to ensure the ruleset will be changed soon after we enable native HTTPS. MediaWiki developer Roan Kattouw, who is also the developer responsible for the protocol-relative URL support, made a git branch and changed and tested the new HTTPS rulesets for HTTPS Everywhere. Hopefully you’ll see the changes in place soon.
How is this implemented?
We have fairly detailed public documentation on how this is implemented. We’ve also very recently released our puppet configuration in a public git repository, so you can see the exact configuration as well:
- The nginx configuration: manifest, nginx site template, main nginx config template
- The ssl node configuration (see ssl[1-4], ssl100[1-4], ssl300[1-4])
- The LVS/pybal configuration: manifest, template
- The MediaWiki configuration: CommonSettings.php, InitialiseSettings.php