The future of HTTPS on Wikimedia projects

Translate this post

The Wikimedia Foundation believes strongly in protecting the privacy of its readers and editors. Recent leaks of the NSA’s XKeyscore program have prompted our community members to push for the use of HTTPS by default for the Wikimedia projects. Thankfully, this is already a project that was being considered for this year’s official roadmap and it has been on our unofficial roadmap since native HTTPS was enabled.
Our current architecture cannot handle HTTPS by default, but we’ve been incrementally making changes to make it possible. Since we appear to be specifically targeted by XKeyscore, we’ll be speeding up these efforts. Here’s our current internal roadmap:

  1. Redirect to HTTPS for log-in, and keep logged-in users on HTTPS. This change is scheduled to be deployed on August 21, at 16:00 UTC. Update as of 21 August: we have delayed this change and will now deploy it on Wednesday, August 28 at 20:00 UTC/1pm PT.
  2. Expand the HTTPS infrastructure: Move the SSL terminators directly onto the frontend varnish caches, and expand the frontend caching clusters as necessitated by increased load.
  3. Put in engineering effort to more properly distribute our SSL load across the frontend caches. In our current architecture, we’re using a source hashing based load balancer to allow for SSL session resumption. We’ll switch to an SSL terminator that supports a distributed SSL cache, or we’ll add one to our current solution. Doing so will allow us to switch to a weighted round-robin load balancer and will result in a more efficient SSL cache.
  4. Starting with smaller projects, slowly soft-enable HTTPS for anonymous users by default, gradually moving toward soft-enabling it on the larger projects as well. By soft-enable we mean changing our rel=canonical links in the head section of our pages to point to the HTTPS version of pages, rather than the HTTP versions. This will cause search engines to return HTTPS results, rather than HTTP results.
  5. Consider enabling perfect forward secrecy. Enabling perfect forward secrecy is only useful if we also eliminate the threat of traffic analysis of HTTPS, which can be used to detect a user’s browsing activity, even when using HTTPS.
  6. Consider doing a hard-enable of HTTPS. By hard-enable we mean force redirecting users from HTTP pages to the HTTPS versions of those pages. A number of countries, China being the largest example, completely block HTTPS to Wikimedia projects, so doing a hard-enable of HTTPS would probably block large numbers of users from accessing our projects at all. Because of this, we feel this action would probably do more harm than good, but we’ll continue to evaluate our options here.
  7. Consider enabling HTTP Strict Transport Security (HSTS) to protect against SSL-stripping man-in-the-middle attacks. Implementing HSTS could also lead to our projects being inaccessible for large numbers of users as it forces a browser to use HTTPS. If a country blocks HTTPS, then every user in the country that received an HSTS header would effectively be blocked from the projects.

Currently we don’t have time frames associated with any change other than redirecting logged-in users to HTTPS, but we will be making time frames internally and will update this post at that point.
Until HTTPS is enabled by default, we urge privacy-conscious users to use HTTPS Everywhere or Tor [1].
Ryan Lane
Operations Engineer, Wikimedia Foundation
[1]: There are restrictions with Tor; see Wikipedia’s information on this.

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

Can you help us translate this article?

In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?

83 Comments
Inline Feedbacks
View all comments

[…] Wikimedia Foundation today announced its response to yesterday’s leaks regarding the NSA’s XKeyscore program: turning on […]

[…] Wikimedia Foundation today announced its response to yesterday’s leaks regarding the NSA’s XKeyscore program: turning on HTTPS by […]

[…] Wikimedia Foundation today announced its response to yesterday’s leaks regarding the NSA’s XKeyscore program: turning on HTTPS by […]

[…] Wikimedia Foundation today announced its response to yesterday’s leaks regarding the NSA’s XKeyscore program: turning on […]

[…] Wikimedia Foundation today announced its response to yesterday’s leaks regarding the NSA’s XKeyscore program: turning on Leia […]

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

ryan, thank you for the detailled information! one detail i am still unsure about, how does this help against man in the middle attacks via the certification authority “digicert”, located in the USA:
* http://www.wired.com/threatlevel/2010/03/packet-forensics/
* https://www.eff.org/deeplinks/2010/03/researchers-reveal-likelihood-governments-fake-ssl

Rupert, this does not protect against MITM attacks via signed certificated from CAs. However, there’s no evidence that it is being done on any large scale. Also, if done on any large scale, we hope that projects like the SSL observatory will detect this type of abuse, prompting browsers to remove malicious CAs from trusts.

[…] Wikimedia Foundation, backers of Wikipedia, says it’s moving to SSL by default in response to being ”specifically targeted by [NSA's] XKeyscore” […]

[…] aren’t changing the web in any way, take a look at this. The Wikimedia foundation has announced that it will be making online encyclopedia Wikipedia HTTPS by default from 21 […]

I was very pleased to read this announcement and I applaud the steps Ryan and the WMF are taking to protect the privacy of Wikipedia readers and editors.
My only (very minor) quibble is with the last sentence of this posting — *everyone*, not just the “privacy conscious”, should be using tools such as HTTPS Everywhere. These technologies aren’t for furtive paranoiacs; they help restore the sanctity of personal communication that was once commonplace.

[…] acciones que van a llevar a cabo las podéis leer en el post han publicado detallando el roadmap interno, el cual irán actualizando a medida que vayan estableciendo fechas […]

Is there some link (on mediawiki.org or elsewhere) where this year’s roadmap mentions this deployment of HTTPS? I mean an other more stable ressource than this blog post; I didn’t found it on https://www.mediawiki.org/wiki/Roadmap

[…] acciones que van a llevar a cabo las podéis leer en el post han publicado detallando el roadmap interno, el cual irán actualizando a medida que vayan estableciendo fechas […]

It’s nice to protects Users privacy. But in China, Mainland, we can’t use Wikipedia with SSL since May, 2013 (Except IPv6, You know why).
If every Chinese has to use SSL, which means there will be no log in from mainland-China-IP, it will destroy the community of Chinese mainland. The wikimania 2013 will be The Last Supper of us.
Sorry for my poor English,
Ranyv, User:燃玉 of zh-Wikipedia
To boldly go where no man has gone before
勇踏前人未至之境!

HTTPS is unavailable in China. Redirect to HTTPS for log-in, and keep logged-in users on HTTPS EQUAL banning ALL China users to visit wikipedia.

Is it possible to only hard-enable HTTPS in countries that does not block it?

loks mith made a key on 2008/8/4 alredy coolden will publish wikip.private.k to proo we

Chinese government didn’t ban Wikipedia from China. Wikimedia Foundation did the final move. Shame on the Foundation.

[…] As one can imagine, there are plenty of technological obstacles that the foundation must overcome, so it’s going through the process a little at a time. The foundation has outlined its current roadmap in a blog post. […]

I’m confused about the comments regarding China. I thought I made it fairly clear that we believe hard-redirecting users to HTTPS would probably do more harm than good and specifically mentioned China as to why it would be. For the foreseeable future HTTP will still be available, but it won’t be the default.

Tristan, HTTPS Everywhere is known to cause browsing issues on many sites, otherwise I would have worded that sentence differently. I would love everyone to use it specifically for the SSL Observatory feature.

Quark, yes, we know forcing log-in over HTTPS will cause problems for editors in China, but it’s honestly dangerous to edit in China without using a VPN or Tor. Additionally, it’s simply poor security practice to allow log-ins over HTTP, as your credentials are being passed across the internet for anyone to steal. We can’t allow China or any other country that censors its users to dictate our security. Please read the Wikipedia article linked in the footnotes for WP:TOR. It lists technical measures you can use to bypass the great firewall of China. That will work for editing. Reading… Read more »

Magnus, not really. We could use Javascript to detect if HTTPS is available and rewrite all links on the page to make subsequent requests HTTPS. We could also use geo targeting via Javascript, but it may not be accurate enough.

Seb35, it’s not on the Roadmap yet, but we’ll hopefully add it soon. We need to figure out reasonable target dates for each action.

Ryan Lane: Default HTTPS at now does not give China average users any benefits, only can not edit and not log in. So, frist, redirecting to HTTPS bans ALL China users to visit and edit wikipedia. Second, most of China registered users will turn to use IP-account and HTTP to visit and edit after HTTPS defaulted, and more IP privacy will be exposeed. In IP-HTTP, the user’s privacy status will be more worse than now loged account. I can not picture it is a feast or a nightmares to China users. VPN and Tor is too difficult and expensive to… Read more »

quark, you’re misunderstanding. The blog post very explicitly says we are not planning on hard redirecting readers to HTTPS. That said, we are planning on hard redirecting log-ins to HTTPS very soon and that will block out Chinese editors behind the GFW.
By using VPNs or Tor it’s possible to continue editing. It’ll be possible to continue reading even without VPNs or Tor, even after we “soft-enable” HTTPS for anonymous users.

Ryan, you should understand that NOT every single Chinese people knows how to use the VPN and Tor. You know how to use it, BUT there are millions of people do NOT know how to use it, Especially when almost all those common proxies were blocked by Wikipedia (Goagent, etc).
You guys should understand that “redirect” can completely destroy the Chinese Wikipedian community. “Access” is much more important than “Security”. if anyone can not even access to a page, he can’t do anything, and his account will worth nothing.

[…] stated in its blog that : “Our current architecture cannot handle HTTPS by default, but we’ve been […]

Ryan Lane: The blog said that “Redirect to HTTPS for log-in, and keep logged-in users on HTTPS. This change is scheduled to be deployed on August 21, at 16:00 UTC.” That mean ALL log-in and logged-in users use wikipedia must be in HTTPS, is it?

Ryan, I have to restate that Wikipedia should be open for edit for anyone, not a few experts in computer science that knows how to use complicated things such as Tor. It is clear that you know “hard redirecting log-ins to HTTPS very soon will block out Chinese editors behind the GFW”(reply #16 ), which is the last thing we would like to happen. It means most active participants from mainland China will either have to leave the community completely or to continue editing as an anonymous editor. Additionally, I find it very difficult to understand ” It’s honestly dangerous… Read more »

Editing over HTTP as a logged-in user provides a false sense of privacy. Communications in China and everywhere else in the world, as we’ve recently become aware, are being monitored. If someone edits as a logged-in user over HTTP their privacy is already gone. Editing over HTTPS makes it much more likely for a logged-in user to stay anonymous. We’re making a choice of real privacy for the world over a false sense of privacy for Chinese users. We can’t control the Chinese government and we can’t allow them to dictate our security policy. Take in mind that I don’t… Read more »

[this comment was merged into the previous comment so that it would appear in the first page of comments]

Re. Perfect Forward Secrecy.
I think perfect forward secrecy is very important. You passed over it with out really explaining yourself.
“Enabling perfect forward secrecy is only useful if we also eliminate the threat of traffic analysis of HTTPS.”
So are you going to eliminate the threat of traffic analysis of HTTPS? If not why not?
Regards, Ciara.

Ciara: Sorry I didn’t go into detail here. Note that we’re considering PFS, but feel it’s more important to make changes to make traffic analysis less effective, otherwise there’s no strong reason to use PFS as decryption of the data wouldn’t be necessary to know a user’s browsing habits. The basic idea is that we have a number of domains that each serve different sets of content (text, upload, bits). When loading an article, s browser will get the HTML from text, then will load the resources in the defined order, since HTTP pipelining is disabled on basically every browser.… Read more »

[…] acciones que van a llevar a cabo las podéis leer en el post han publicado detallando el roadmap interno, el cual irán actualizando a medida que vayan estableciendo fechas […]

OK. Let’s celebrate MWF give China users last straw. China users for the MWF is worthless. MWF does care whether the China users can actually use Wikipedia. Fine, we will done. All Chinese will see you guys to protect your privacy from the hell. I feel ashamed for MWF.

quark: I think it’s likely you missed my comment mentioning we’re discussing options internally for Chinese users. We’re not enabling this for another 3 weeks, so it’s likely we’ll find a reasonable alternatives within this time. Additionally, if we’re unable to implement a reasonable alternative we may simply not enable this for Chinese projects.
This is rather unfortunate situation for Chinese project editors outside of mainland China, which is roughly 79% of editors.

I think Wikimedia Fondation may establish http://insecure.wikimedia.org/wikipedia/zh/wiki for Chinese users. It’s been declared in the url the connection is insecure, and additional warnings can be added, so users will be informed if they visit this special site.

the master: Someone has suggested this as a solution on bugzilla and I’ve extremely wary of that approach from a technical point of view. I put in quite a bit of effort to rid our infrastructure of secure.wikimedia.org and would be against adding something similar back in. There’s likely much better alternatives that we can take than this.

[…] acciones que van a llevar a cabo las podéis leer en el post han publicado detallando el roadmap interno, el cual irán actualizando a medida que vayan estableciendo […]

Why not just leave default log-in page in HTTP rather than HTTPS for Chinese wikipedia projects(Not just zhwiki, but also wikis related to those in the ISO639-3 zho family) and provide a link to HTTPS and write something to STRONGLY RECOMMEND editors to use it?
In a nutshell, strongly recommend rather than hard redirect.

Another alternative way would be to check the IP the editor is using and decide whether to or not to hard redirect to HTTPS.

> If a country blocks HTTPS
Has this ever happened?

Matt: China blocks Wikimedia projects on HTTPS currently, yes.

[…] un communiqué, la fondation Wikimédia déclare « croire fermement à la protection de la vie privée […]

Even if this “feature” is brought into practice, I would still strongly recommend you not to enable it on Chinese Wikipedia (zh), as for the reason that Quark stated. You are free to enable it elsewhere.

[…] un communiqué, la fondation Wikimédia déclare « croire fermement à la protection de la vie privée […]

As a 5-year Wikipedia editor, I appreciate for WMF’s efforts on every promotion, including security protection. However, this attempt of moving to HTTPS on Wikimedia projects will completely destroy the Chinese community to reach all the Wikimedia programs, not only Zh-wikipedia. Since 2008, our Chinese Wikipedia has suffered governmental blocks for different reasons. Although we could access the HTTPS early 2013, the government still blocked this method to reach Wikipedia immediately, when we recommended this in public. Many Wikipedia-unfriendly governments would learn and act same as the Chinese Government on internet control – which means, if WMF act HTTPS on… Read more »

[…] Le communiqué de Wikimédia sur son blog […]

Very interesting. Seeing as we are talking about eavesdropping by those with the resources a nation state (NSA et al.) doesn’t the finger printing by traffic analysis issue also compromise the perceived privacy provided by ‘vanilla’ HTTPS? If so, are the measures described in the blog really just giving ourselves a false sense of privacy (regarding NSA level eavesdropping)?

So, HTTPS forces them to do traffic analysis, which makes their lives quite a bit harder. So, it’s not a false sense of security, but isn’t by itself a complete solution. As mentioned, newer protocols will likely help this situation, but we’ll also be putting effort into making traffic analysis more difficult for our traffic. Our first priority, of course, is moving people to HTTPS.

For clarity – the above comment #9 , is a follow-on from my previous comment #2 on page 2

So much for clarity! That should read the above comment #10

[…] The Wikimedia Foundation is working on making its projects more secure to protect users’ privacy. As one can imagine, there are plenty of technological obstacles that the foundation must overcome, so it’s going through the process a little at a time. The foundation has outlined its current roadmap in a blog post. […]