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?

  • 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.
  • We can remove our CSS, Javascript, and web server hacks. This simplifies everything, and makes it far less likely we’ll have mixed-content issues.

What will happen to 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:

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
18 Show

18 Comments on Native HTTPS support enabled for all Wikimedia Foundation wikis

Tilman 3 years

Manual pingback: http://googlewebmastercentral.blogspot.com/2011/10/accessing-search-query-data-for-your.html (“SSL encryption on the web has been growing by leaps and bounds”)

Ryan Lane 3 years

@Tgr: At this time I don’t believe we have any open bugs related to protocol-relative URLs, but I could be wrong. They have been fairly reliable.

Tgr 3 years

Great news; the lack of proper HTTPS was a long-time technical debt of Wikimedia. I second that there should be a user option to always use HTTPS (STS headers are a good thing, but many browsers do not understand them, so there should be some sort of server-side redirection as a fallback, too).

Protocol-relative script URLs are also great news, but how reliable are they? This post says that they can sometimes fail on IE6: http://paulirish.com/2010/the-protocol-relative-url/

Ryan Lane 3 years

@Ben: We have an https cluster in every datacenter. We will likely open more regional datacenters in the future, but we don’t have any immediate plans. Yes, with https everything still goes through the cache. This secure service will always be much faster and more reliable than secure.wikimedia.org.

Ryan Lane 3 years

@Mace: it’s possible to use https on a mobile device, but not with the mobile view.

Ryan Lane 3 years

@Kam-Yung mobile is in scope for the future, but not right at this moment, since mobile in the middle of a re-write.

Ryan Lane 3 years

@Terence Unfortunately, due to the way m. domains work, we can’t do this right now. In the future mobile will likely use the regular domain (just en.wikipedia.org, for instance), and when that happens it’ll be much easier to enable HTTPS.

Ryan Lane 3 years

@Tom: There have been talks about this that would be slightly more secure than just doing it via javascript. Basically we’d set STS headers for users that have already authenticated over https. We already mark the cookies as secure, so thankfully it isn’t possible to steal user cookies when using https.

Tom Morris 3 years

Just made a simple JavaScript to autoforward from HTTP to HTTPS.

https://en.wikipedia.org/wiki/User:Tom_Morris/https.js

It’d be nice if this could be in the user preferences, like it used to be for Gmail etc.

Tom Morris 3 years

Are there any plans to make it so that logged-in users can specify (either on a project or a global level) that they want to always be taken to the HTTPS version – basically like HTTPS Everywhere but done at the user settings level rather than the browser level.

If not, I might try and hack together a user skin.js addon to autoforward to HTTPS. Having HTTPS-by-default in user settings would be especially useful for people with higher permissions (crats, stewards, checkusers, oversighters, founders etc.).

Terence Eden 3 years

Just to second the call for a secure mobile site.
https://en.m.wikipedia.org doesn’t work, nor do any *.m sites.

Kam-Yung Soh 3 years

The mobile wikipedia [ http://en.m.wikipedia.org/ ] does not appear to work via https [ https://en.m.wikipedia.org ]. Will this be fixed?

Mace Moneta 3 years

That should have been: en.m.wikipedia.org, of course.

Mace Moneta 3 years

The mobile site: en.wikipedia.org doesn’t accept an https connection, and the ‘view mobile’ link at the bottom of each page doesn’t maintain a mobile view. So no security for mobile users?

Ben 3 years

It’s still going to be slow while the web site is so far away. Are there any plans to have closer regional proxies in place?

And with this https is that still being cached by the caches?

Ryan Lane 3 years

A goal of mine in this project is to have all logins go via https, which means all editor actions as well. If performance is a problem we’ll add some more nodes.

Darkoneko 3 years

with the new system, how heavy would be the impact on server load if most editors suddenly started using the secure version ?

it’s plausible seeing how easy it became to do :)

Anonymous 3 years

THANK YOU! Excellent that you’re being proactive with the HTTPS Everywhere addon, too.

Leave a Reply

Your email address will not be published. Required fields are marked *