HTTPS is a web protocol that improves the security of communication between the user and the server. With it enabled:
- you can be sure the content you are viewing has not been modified by any intermediary such as an ISP or government system;
- you can have a reasonable expectation that nobody knows what pages you are visiting, and
- you can be sure nobody can change the content of your edits during their transport to the Wikimedia servers.
The continued work to improve the security and privacy of Wikimedia project users is a stated goal of the Wikimedia Foundation. This work has been escalated in prominence by the United States National Security Agency (NSA) domestic spying scandal revealed by Edward Snowden in the summer of 2013. The Wikipedia project was referenced in several documents as a specific source for tracking users’ behavior online. Browsing the web via the insecure HTTP protocol allows third-parties to track what pages you view and information you send online.
- 1 What this means for you
- 2 Excluded Countries
- 3 Disabling
- 4 Help!
- 5 Help! My code is broken!
- 6 Various small problems
- 7 History of HTTPS at WMF
- 8 Links
What this means for you
In addition to the previous improvements to privacy and security on Wikimedia sites (see below), on Wednesday August 28, 2013, 1pm PDT, the Wikimedia Foundation will default to HTTPS for all logged in users. How this works is simple: If a user wants to login, the login will happen over HTTPS (thus keeping their username and password secure), and after they are logged in they stay on the HTTPS version of the Wikimedia site they are using.
Some users live where HTTPS is not an easy option due to explicit blocking by government. At the request of these communities, we made an explicit exclusion for users from those particular countries. Simply, users from China and Iran will not be required to use HTTPS to log in, nor to view any Wikimedia project site.
Are you having a slow or unreliable experience while browsing Wikimedia sites over HTTPS? If so, you can turn off HTTPS in your user preferences (unless HSTS is set for the domain in question). Go to the "User profile" tab, then uncheck the box labelled "Always use a secure connection when logged in". You will need to logout and login for the preference to take effect. But remember, you will still need to log in using HTTPS.
Are you unable to login and edit a Wikimedia wiki after this change? Please contact the Wikimedia Foundation Operations team via any means you find comfortable including this article's talk page, on IRC in the #wikimedia-operations channel, or via the firstname.lastname@example.org email address.
If you are behind a proxy, for instance a caching proxy to improve web experience in a place with bad networking, and the proxy prevents you from using Wikimedia sites over HTTPS, please contact the maintainers of the proxy and ask them if they can fix it, and if not why.
In limited, controlled environments like schools and corporations, where the entity also controls the browsers/devices, they can technically proxycache HTTPS. There are commercial solutions to do so which rely on, basically, installing a fake root certificate into the browsers/OSs, which their proxycache uses to generate fake SSL certs for the sites being proxied, etc.
Help! My code is broken!
Are you a bot maintainer or Gadget author and you're seeing weird or broken behavior after this switch? Hopefully you can fix that easily.
For Gadget authors, simply modifying any hardcoded urls from "http://..." to "//..." should fix the issue (this is called using "protocol relative urls").
For bot maintainers, you have a couple of choices. Either login as the bot and select the preference to not use HTTPS for that account, or update your code to use SSL instead. If you use Pywikipediabot, please update to the latest version (More technical details: ,) and read this mailing list post for more information.
Various small problems
If images are missing, check if you can see for instance this thumb image from Commons. If you get a certificate warning and accept it, you should see images afterwards (although you shouldn’t have a certificate warning, please see the next section about this).
If you had custom scripts that you retrieved by calling a function
importScriptUri, you should change the function or the syntax to call scripts with
"https://..." or better yet, with protocol-relative URL's like this,
"//..." without the
https:. In any case, there is a generic function in the MediaWiki:Common.js of your wiki that is preferable to a custom function.
If you are still using syntax like document.write('<script src="http://..." />'); replace it immediately with
mw.loader.load, because the
document.write methodology can easily break in certain browsers.
Certificate error or warning
If your browser silently removes the safe in the address bar (or bottom of your browser) or explicitly issues a warning:
- you can check if your computer clock is up-to-date: since the HTTPS certificate is valid during a specific time range (January 2012-January 2016 for Wikimedia projects), any bad clock will generate a warning;
- you can check whether you have the authority certificate with the following explanations; if you don’t find it, please report in the talk page
- Firefox: go to Edit > Preferences > Advanced > Encryption > View Certificates > Authorities and you should find the certificate "Digicert Inc" > "DigiCert High Assurance EV Root CA";
- Opera: go to Tools > Preferences > Advanced > Security > Manage Certificates > Authorities and you should find the certificate "DigiCert High Assurance EV Root CA";
- check the site you are visiting is really Wikipedia or a Wikimedia project: the address bar should be
https://your-language.wikipedia.orgor the exact name of your project; if there are strange characters in the address bar (dashes in the project name, unusual slashes, etc.) this is possibly a fake website, please report it in the talk page https://meta.wikimedia.org/wiki/Talk:HTTPS
- check if you also have a certificate error in the domains upload.wikimedia.org and bits.wikimedia.org
- report it in the talk page and specify your browser, your browser version (generally in the browser menu Help > About), your operating system and its version.
Effect on unregistered contributors
A switch of Wikimedia projects to HTTPS would mean that unregistered contributors have no means to disable it, since Special:Preferences is unavailable to them. This may have some implications (HTTPS may be slow in some misconfigured internet access points, for instance).
History of HTTPS at WMF
Initial activation in 2005
HTTPS was first activated on the Wikimedia projects by Brion in December 2005, although it was on special URLs of the form
https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page and it was quite slow and unscalable (one single server for this task), making it unsuitable for everyone’s use.
Large-scale deployment in 2011
HTTPS with canonical URLs
https://en.wikipedia.org/wiki/Main_Page was activated in October 2011, after months of effort to make it work in a cache-friendly manner. This meant that
- protocol-relative links could be used, to avoid caching two versions of the same page;
- correctly setting up servers and caching to handle HTTPS; and
- ensuring that all resources were served using the same protocol, either HTTP or HTTPS, to avoid mixed content on the page (mixed content negates the secure state of the page).
August 28, 2013 - Secure log-in, with secure browsing and editing for logged in users
Per the plan laid out in the blog post titled "The future of HTTPS on Wikimedia Projects", as of Wednesday, August 28, 2013 at 1pm PDT (that's 20:00 UTC), logging in will be done using HTTPS for the majority of editors and projects. (We originally announced that the change would take place on August 21st; we've pushed that date one week back.) Logged-in users will browse and edit using HTTPS by default.
- General links:
- Jimmy Wales’ tweet, see the linked image leaked from a "top secret" document.
- See the explanation by a Wikimedia Foundation sysadmin.
- "Wikitech-l: HTTPS for logged in users delayed. New date: August 28"