Securing access to Wikimedia sites with HTTPS

Translate this post

To ensure that Wikipedia users can share in the world’s knowledge more securely, the Wikimedia Foundation is implementing HTTPS, to encrypt all traffic on Wikimedia sites.Image by Hugh D'Andrade, from Electronic Frontier Foundation, freely licensed under CC BY-SA 3.0.
To ensure that Wikipedia users can share in the world’s knowledge more securely, the Wikimedia Foundation is implementing HTTPS, to encrypt all traffic on Wikimedia sites.
Image by Hugh D’Andrade, from Electronic Frontier Foundation, freely licensed under CC BY-SA 3.0.

To be truly free, access to knowledge must be secure and uncensored. At the Wikimedia Foundation, we believe that you should be able to use Wikipedia and the Wikimedia sites without sacrificing privacy or safety.
Today, we’re happy to announce that we are in the process of implementing HTTPS to encrypt all Wikimedia traffic. We will also use HTTP Strict Transport Security (HSTS) to protect against efforts to ‘break’ HTTPS and intercept traffic. With this change, the nearly half a billion people who rely on Wikipedia and its sister projects every month will be able to share in the world’s knowledge more securely.
The HTTPS protocol creates an encrypted connection between your computer and Wikimedia sites to ensure the security and integrity of data you transmit. Encryption makes it more difficult for governments and other third parties to monitor your traffic. It also makes it harder for Internet Service Providers (ISPs) to censor access to specific Wikipedia articles and other information.
HTTPS is not new to Wikimedia sites. Since 2011, we have been working on establishing the infrastructure and technical requirements, and understanding the policy and community implications of HTTPS for all Wikimedia 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 directed to our sites from major search engines. Additionally, all logged in users have been accessing via HTTPS since 2013.
Over the last few years, increasing concerns about government surveillance prompted members of the Wikimedia community to push for more broad protection through HTTPS. We agreed, and made this transition a priority for our policy and engineering teams.
We believe encryption makes the web stronger for everyone. In a world where mass surveillance has become a serious threat to intellectual freedom, secure connections are essential for protecting users around the world. Without encryption, governments can more easily surveil sensitive information, creating a chilling effect, and deterring participation, or in extreme cases they can isolate or discipline citizens. Accounts may also be hijacked, pages may be censored, other security flaws could expose sensitive user information and communications. Because of these circumstances, we believe that the time for HTTPS for all Wikimedia traffic is now. We encourage others to join us as we move forward with this commitment.
The technical challenges of migrating to HTTPS
HTTPS migration for one of the world’s most popular websites can be complicated. For us, this process began years ago and involved teams from across the Wikimedia Foundation. Our engineering team has been driving this transition, working hard to improve our sites’ HTTPS performance, prepare our infrastructure to handle the transition, and ultimately manage the implementation.
Our first steps involved improving our infrastructure and code base so we could support HTTPS. We also significantly expanded and updated our server hardware. Since we don’t employ third party content delivery systems, we had to manage this process for our entire infrastructure stack in-house.
HTTPS may also have performance implications for users, particularly our many users accessing Wikimedia sites from countries or networks with poor technical infrastructure. We’ve been carefully calibrating our HTTPS configuration to minimize negative impacts related to latency, page load times, and user experience. This was an iterative process that relied on industry standards, a large amount of testing, and our own experience running the Wikimedia sites.
Throughout this process, we have carefully considered how HTTPS affects all of our users. People around the world access Wikimedia sites from a diversity of devices, with varying levels of connectivity and freedom of information. Although we have optimized the experience as much as possible with this challenge in mind, this change could affect access for some Wikimedia traffic in certain parts of the world.
In the last year leading up to this roll-out, we’ve ramped up our testing and optimization efforts to make sure our sites and infrastructure can support this migration. Our focus is now on completing the implementation of HTTPS and HSTS for all Wikimedia sites. We look forward to sharing a more detailed account of this unique engineering accomplishment once we’re through the full transition.
Today, we are happy to start the final steps of this transition, and we expect completion within a couple of weeks.
Yana Welinder, Senior Legal Counsel, Wikimedia Foundation
Victoria Baranetsky, Legal Counsel, Wikimedia Foundation
Brandon Black, Operations Engineer, Wikimedia Foundation

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?

84 Comments
Inline Feedbacks
View all comments

Will concrete information be made available on https://meta.wikimedia.org/wiki/HTTPS ? Example question: when will HTTPS made universal on the wikis which asked it some years ago?

@nemobis Thanks for pointing out this meta page. We will try to provide more info there eventually, but have our hands full with the rollout. In the meantime, if you would like to use the information in this post to respond to questions, that would be incredibly helpful.

Hi, Greetings!
Glad to see Wiki turns on HTTPS by default. However, can I turn off HTTPS? Since the GFW in China blocks Wiki in HTTPS sometimes, and it takes far more time to load the site.
Regards

Thank you! #EncryptTheWeb

Yana, I’m sorry but I’m unable to extract any information from this post. However, I linked it from there and updated a local it.wiki discussion with clarifications provided by ops.

I’m glad to finally see this. Thanks.

PLEASE leave users the possibility to opt out of HTTPS; why has it now been taken away?
I don’t care about intelligence agencies spying on my Wikipedia contributions, if they ever do; I just want the best possible performance AND I’m happy to save the Wikimedia infrastructure valuable processing time, by avoiding something for me completely pointless, i.e. encryption.
Shouldn’t Wikipedia be all about freedom? Then turn on HTTPS by default if you want, and then leave the user free to decide whether to turn it off or not.
Thank you.

This is a major step forward.

Makes the web a little bit safer.

“We’ve been carefully calibrating our HTTPS configuration to minimize negative impacts related to latency, page load times, and user experience.”
Can you please expand on this in more detail? More specifically how you decided to make tradeoffs of speed and performance and cipher suites used?

Old OPERA (12.16) stop working

This is great news! Everything should be encrypted by default, so that it does not look suspicious when one really needs encryption (like when searching for an illness or for chapter 11 information).

The browser I use most (99 %) is Arachne running in DOS.
Arachne does not do HTTPS.
Is there any way I can access Wikipedia WITHOUT HTTPS ??

To elaborate on the post by Ron Clarke:
Ron & I are active developers of DOS Arachne available at…
http://glennmcc.org/
The page for-which on wikipedia is no longer accessible to DOS Arachne
due to https being required.
https://en.wikipedia.org/wiki/Arachne_(web_browser)
Before this change to https, DOS Arachne was indeed able to access that page via…
http://en.wikipedia.org/wiki/Arachne_(web_browser)
However, attempting to access via http now auto-rediects to https
Please, re-think your position of requiring https access.
“free” information is not so “free” after-all if accessing said information has the string
attached of requiring a protocol that is not available in _all_ web browsers.

Will this affect the status of the ongoing NSA lawsuit by Wikipedia? Is there any need for the lawsuit, if editors and readers are all accessing Wikipedia via HTTPS?

It would be a great idea if it worked, sadly Wikipedia seems to have died for me in FF3. I’m getting an error message saying “The connection was interrupted”.
Works fine in IE.

@Arachne_running_in_DOS, you already have a problem today with other SSL/TLS sites like e-banking etc. Why now adding a SSL/TLS support to that browser instead, is this really something very hard to do, or just not a priority? @All_users_who_do_not_respect_privacy, actually I think you are honest, everyone want privacy, but some do not understand it. Everyone that do not need privacy, please create web page, publish all your passwords and also please upload all of your personal information – your telephone SMS, photos, all e-mail conversations, etc. You said you don’t care about privacy, so this should not be a problem. Let’s… Read more »

@Steve
Please try to be a little less gratuitously antagonistic to prior comments, okay? The content about government pedophiles is extreme in this context
http://diff.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/#comment-24274

@Glenn McCorkle and Ron Clarke: “Ron & I are active developers of DOS Arachne” This ship has sailed. Every single .gov domain will be HTTPS-only by next year. Many already are. For active developers of web browsers which don’t support HTTPS, implementing it should have been the number one priority for the last few years, because other browsers – even other command-line browsers that can run on legacy hardware – support it just fine. Like an FTP program without FTPS or SFTP, or an email program without STARTTLS, you’ll lose market share and relevance. Oh, and IPv6 URLs are a… Read more »

Steve,
> Why now adding a SSL/TLS support to that browser instead, is this really something very hard to do, or just not a priority?
Adding SSL to Arachne would be wonderful, and we wish we could. But…..we have a lack of suitably skilled coders with an interest in DOS browsers, and Arachne in particular.
Any volunteers ?

Now all IE6 users will be cut off from using Wikipedia:
https://www.ssllabs.com/ssltest/analyze.html?d=en.wikipedia.org
Wouldn’t it be possible to add some user-agent sniffing so that these browsers could still access Wikipedia? They are usually used by poorer people.

“Wouldn’t it be possible to add some user-agent sniffing” NO! No it would not. Because then a man in the middle can replace anyone’s user agent details with another user agent, and bingo, nobody any longer has any encryption at all. Invisibly and undetectably. Why would wikimedia hand attackers such a gift on a plate? Upgrading from IE6 to a secure browser is entirely possible for every single user on the planet. There is no sane reason for anyone, anywhere, to use an insecure browser. The very worst smartphone and smartwatch in the world can browse securely. Even Lynx can… Read more »

“Because then a man in the middle can replace anyone’s user agent details with another user agent, and bingo, nobody any longer has any encryption at all. Invisibly and undetectably.” Such an attack is already possible with tools such as sslstrip. Therefore user-agent sniffing doesn’t decrease security for other users out there: it will make life easier neither for criminals nor for companies that want to monitor traffic. Wikipedia is going to use HSTS and add itself to HSTS preload lists in browsers: that will block downgrade to HTTP for new browsers. “Upgrading from IE6 to a secure browser is… Read more »

I *really* want the ability to connect without HTTPS. I want to avoid the overhead required by HTTPS please.

> There are two reasons someone might ask for any form of downgrade or opt-out to be permitted:
Make that three reasons.
I run in DOS, and I like to keep the functionality of Arachne.
Yes, I also run Links, Elinks and Lynx in DOS, but Arachne is more versatile than all of them – except for a lack of SSL.

Very good step indeed, in fact, in cyber world https is more important because of security issues. Know a days users check website also they check that website https not. If they found https is not they click on cut button and skip from website…

Great move team. Web is becoming a tool for governments and enforcement agencies to surveillance on citizens. SSL helps website visitors to send and receive encrypted data.
I also want to move my website http://careervendor.com from HTTP to HTTPS. I am fearing about loosing traffic, backlink and ranking. Can anyone please suggest a way for proper migration.

Very good step indeed, in fact, in cyber world https is more important because of security issues. Know a days users check website also they check that website https not. If they found https is not they click on cut button and skip from website…

All well and good to force everyone to use https. Would it be too much to ask to employ a real SSL certificate that doesn’t rely on a wildcard. At present, we can’t even use Wikipedia anymore because we can’t trust the website. Uggghhh…

All the points are explained very clearly, Great source of information. Thanks for en-lighting us with your knowledge, it is helpful for many of us.

Great step for sure, actually, in digital world https is more imperative

Is there *any* way to use Wikipedia *without* https? I have an old device which is not capable of using https. And please don’t tell me to buy new hardware or software. So please offer a possibility to read Wikipedia *without* forced https!!!! BTW: I cannot follow the reasons to *enforce* https: Concerning privacy: when you browse Wikipedia the URLs contain the topic you are reading (e.g.: https://en.wikipedia.org/wiki/CMAC) thus any sniffer can track what you are currenly reading. Only the *contents* is encrypted, but the contents is visible by anybody anyway (in contrast to the content of my bank account).… Read more »

Flo said
“Concerning privacy: when you browse Wikipedia the URLs contain the topic you are reading thus any sniffer can track what you are currenly reading. Only the *contents* is encrypted, but the contents is visible by anybody anyway (in contrast to the content of my bank account).”
False. The root domain (wikipedia.org) can be inferred from the IP address of the server during the TCP/IP request but the complete URL and exact page you’re reading cannot.
Read the article on https.

I also want there is a way to use wikipedia with plain HTTP if necessary. Currently there is a stupid debate between our government and local wiki representatives (I could not decide which of them is more stupid, I’m sorry) about restricting access to certain pages (about drugs). Providers can do this for single page if it is accessed with HTTP, but they need to deny access to whole website if it is accessed via HTTPS. So it would be good if we have some fallback, perhaps with banner explaining “all horrible consequences” of reading wiki in plain HTTP. In… Read more »

[…] in 2015, we began encrypting all of our traffic with HTTPS to ensure that users and readers alike can use our services “without sacrificing privacy or […]

[…] HTTPS fluctuations? Wikipedia moved to HTTPS before 2 months ago, but the serious drop in the organic desktop traffic began actually at […]

[…] has been kind enough to share their thoughts that their shift to HTTPS might have resulted in drops in traffic overall and from search engines :”This switch to […]

[…] dates as these become available; helpful English Wikipedia articles about government surveillance; information about HTTPS access to the projects and online security; and social media action items for anybody […]

[…] June 2015 the Wikimedia foundation made the announcement that they were finalising the switch, and that within a few weeks all traffic would be […]

[…] 实际上已于 2015 年六月 从 HTTP 迁移到了 HTTPS。在那时,几乎所有从 wikipedia.org 到 HTTP […]

[…] 实际上已于 2015 年六月 从 HTTP 迁移到了 HTTPS 。在那时,几乎所有从 wikipedia.org 到 HTTP […]

[…] is presently blocking Wikipedia in its entirety, in part because of the encyclopedia’s recent move to an encrypted “HTTPS” protocol that makes it harder for the government to determine […]

[…] no protocolo de navegação da Wikipédia também ajuda na queda de acessos. Em junho, foi anunciado que os sites da Wikimedia seriam criptografados com o protocolo HTTPS, que garante a segurança e […]

[…] fois, elle a été documentée. C’est pour éviter cela que nous avons pris la décision d’utiliser par défaut le protocole « HTTPS », qui rend la surveillance de votre navigation beaucoup plus difficile, sur toutes les […]

[…] fois, elle a été documentée. C’est pour éviter cela que nous avons pris la décision d’utiliser par défaut le protocole « HTTPS », qui rend la surveillance de votre navigation beaucoup plus difficile, sur toutes les […]

[…] Securing access to Wikimedia sites with HTTPS – 14k views […]

Google usually has an alternate (cache) for each wiki link.
I just use these cache pages.

[…] the use of HTTPS as a rankings signal. Over the past few years, organizations like Facebook, Wikipedia, and the Federal CIO Council have shown that properly switching to HTTPS is no longer the […]

[…] to protect the free expression and privacy rights of all Wikipedia users. We have since enabled default HTTPS access to protect Wikipedia users from government surveillance, and we remain committed to our stringent […]

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy