Native HTTPS support enabled for all Wikimedia Foundation wikis

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 dirty JavaScript hacks that were required to make secure work, thanks to the URL issue above.
• 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?

Links pointing to secure.wikimedia.org will continue to work. The plan is to make URLs on secure.wikimedia.org redirect to the proper HTTPS URLs. secure.wikimedia.org will no longer act as a proxy for the sites.

But, I still get mixed-content warnings!

Unfortunately, the long-tail of this project is very long. Fixing all mixed-content warnings will be a long effort by both the MediaWiki core and extension developers and the project communities. A number of templates, CSS, and Javascript on projects are improperly referencing resources, and as such, they are being loaded incorrectly. All resources should be referenced using protocol-relative URLs now (//<resource-url> vs http://<resource-url>).

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

As a bonus, this is also the configuration for our IPv6 proxies (which are only currently enabled for upload.wikimedia.org).

Ryan Lane

Operations Engineer

Archive notice: This is an archived post from blog.wikimedia.org, which operated under different editorial and content guidelines than Diff.