Securing access to Wikimedia sites with HTTPS

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

31 Show

31 Comments on Securing access to Wikimedia sites with HTTPS

Sports Fan Stan 2 days

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…

astrodevamm 2 days

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…

Pushpendra Pal 2 days

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.

astrodevamm 2 days

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…

Ron 3 days

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

zzo38 7 days

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

Mat2 7 days

“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 entirely possible for every single user on the planet. There is no sane reason for anyone, anywhere, to use an insecure browser.”
Not every computer user can do this, unfortunately.

Google makes sure that IE6 still works:
https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.239.96&hideResults=on
Wikipedia is such an important site on the internet.

dewimorgan 7 days

“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 handle secure browsing, and that’s been ported to just about everything.

There are two reasons someone might ask for any form of downgrade or opt-out to be permitted: 1) they are grievously uninformed; or 2) they are maliciously requesting the downgrade on behalf of some organization which wants a MitM attack to work.

One wonders how many of each group is commenting here.

Mat2 7 days

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.

Ron Clarke 1 week

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 ?

dewimorgan 1 week

@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 thing now, too.

Ellie Kesselman 1 week

@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://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/#comment-24274

Steve 1 week

@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 imagine you have a one year old son/daughter that is swimming naked and you would like to share this image with your parents and that some state spy intercepts this image and maybe (you can never tell) he is a pedophile and this personal image gets published in pedophile network. In this case I think you do want some info to be personal.

@All_users_who_think_non-encrypting_web_pages_should_be_available, some of you have stated, you should have a freedom to access http web pages, but actually you lose nothing (ignoring CPU resources at server/browser site now-days are minimal – few percentage, search Google for there servers using encryption), but on other hand you freedom jeopardize users from all over the word that need encryption to protect themselfs from evil government and in state where almost everyone is using http and just few https, then https-users are suspicious. If everyone is using encryption, then no one is suspicious and so non-lucky users all over the word will be more free (as freedom).

P 1 week

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.

Ellie Kesselman 1 week

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?

Glenn McCorkle 1 week

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.

Ron Clarke 1 week

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 ??

Alexander 1 week

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

nowak 1 week

Old OPERA (12.16) stop working

cosjef 2 weeks

“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?

Leave a Reply

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