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

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

33 Comments
Inline Feedbacks
View all comments

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

[…] 維基百科全面支援 HTTPS (SSL) Posted on October 4, 2011 by Gea-Suan Lin Tweet 維基百科在官方的 Blog 上宣佈,所有的服務都支援 HTTPS (SSL):「Native HTTPS support enabled for all Wikimedia Foundation wikis」,也就是說,像是「https://zh.wikipedia.org/wiki/Wikipedia:首页」這樣的網址都支援了。 […]

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 🙂

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.

[…] to the site’s newly announced support for HTTPS browsing. Ryan Lane, a Wikipedia Operations Engineer, writes that HTTPS “allows you to visit our sites […]

[…] leverage a new level of security and privacy regarding their reading habits, thanks to the site's newly announced support for HTTPS browsing. Ryan Lane, a Wikipedia Operations Engineer, writes that HTTPS "allows you to visit our sites […]

[…] leverage a new level of security and privacy regarding their reading habits, thanks to the site's newly announced support for HTTPS browsing. Ryan Lane, a Wikipedia Operations Engineer, writes that HTTPS "allows you to visit our sites […]

[…] 维基百科游客现在可以利用一个新的水平的安全和隐私,他们的阅读习惯,到现场的新宣布支持HTTPS的浏览。瑞安里,维基百科的运营工程师,写,HTTPS的“允许您访问我们的网站,而不必跟踪您的浏览习惯,您可以登录,而无需您的密码或用户会话数据被盗。 “ 游客浏览网站的安全可以简单地访问https://en.wikipedia.org开始 。 […]

[…] HTTPS Comes To WikipediaBy Jason on October 3, 2011 Wikimedia announced today that all Wikimedia Foundations wikis are now enabled to use native HTTPS. This means that while […]

[…] esos casos seguramente es que Wikipedia ha puesto ya la manera de poner el protocolo https para conectarte a buscar cosas en la enciclopedia. Es decir de esa manera nadie podrá robarte tu contraseña y podrás navegar de manera segura por […]

[…] ที่มา – Wikimedia Blog […]

[…] 维基百科(Wikipedia)发布博文称已启用原生 HTTPS 访问支持。“这允许您访问我们的网站,而不必跟踪您的浏览习惯;您可以无需担心您的密码或用户会话数据被盗而直接登录访问。”维基百科的运营工程师 Ryan Lane 在博文里这样写道。维基百科公布了 HTTPS 的具体配置,并强调相比此前的安全网址,“HTTPS 能够带来更安全的浏览”。 […]

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?

@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.

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?

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

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

[…] Via | Wikimedia Foundation […]

[…] Via | Wikimedia Foundation […]

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

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

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

@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.

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.).

@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.

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.

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/

@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.

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”)

[…] encryption on the web has been growing by leaps and bounds. As part of our commitment to provide a more secure online experience, today we announced […]

[…] Om HTTPS och Wikimediaprojekten Native HTTPS support enabled for all Wikimedia Foundation wikis The future of HTTPS on Wikimedia projects HTTPS by default beta program Om HTTPS på Wikipedia Om […]

[…] traffic, with the ultimate goal of making it available to all users. In fact, for the past four years, Wikimedia users could access our sites with HTTPS manually, through HTTPS Everywhere, and when […]

[…] level: All SSL encryption on the web has been growing by leaps and bounds. As part of our commitment to provide a more secure online experience, today we announced […]