This page is kept for historical interest. Any policies mentioned may be obsolete.
If you want to revive the topic, you can use the talk page
or start a discussion on the community forum
HTTPS (HTTP Secure)
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;
- it makes it much more difficult (but not impossible) for a third party to determine what article you are viewing,
- you can be sure nobody can change the content of your edits during their transport to the Wikimedia servers, and
- you can be sure that nobody can take over your account by stealing your password or session cookie.
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.
Wikimedia used to have a dedicated secure server (secure.wikimedia.org) for HTTPS connections. Now, all connections to Wikimedia projects are encrypted, and unencrypted access is no longer possible, and the URL above redirects to the appropriate Wikimedia project.
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 defaulted 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.
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.
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 Pywikibot, please update to the latest version (More technical details: 
) and read this
mailing list post for more information.
Autocomplete no longer working
Users of Internet Explorer 8, 9 and 10 report that auto-complete of the edit summary field no longer works under HTTPS. This issue can be fixed by upgrading to Internet Explorer 11.
API requests are now being forced redirected to HTTPS on some languages. On most bot frameworks, this should just work, but a few bot maintainers have reported problems. If your bot has problems, make sure that the library you are using supports HTTPS, and has access to appropriate root certificates.
If you had custom scripts that you retrieved by calling a function loadJS
, you should change the function or the syntax to call scripts with
or better yet, with protocol-relative URL's like this, "//..."
without the http:
. 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.org or 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
Once HTTPS is switched fully on, there will be no option to disable, and all users will have to use it (This is necessary to prevent the SSL-stripping attack)
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
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.
In June 2015, the WMF announced
the ongoing transition of all of the Wikimedia wikis to HTTPS, without an ability to opt out.
All wikis are now converted to HTTPS-only. Converting to HTTPS-only entails the following:
- The HTML <link rel="canonical" ..> tag is set to HTTPS. This tells search engines to return the HTTPS version in search results.8f99d5f4a5009b4a
- When visiting the http project in question, the web browser receives a redirect (HTTP 301). This tells the web browser that the website has permanently moved to the HTTPS version.cfc9dbe40323b3157
- HSTS headers are enabled. This tells the web browser that once it has visited the website over HTTPS once, it must always use HTTPS in the future. This prevents people from "opting-out" of HTTPS, but is required to prevent certain attacks on HTTPS where a malicious person could trick the browser into loading the unsecured HTTP version (and then hijack the page) even if the user would normally use HTTPS. c8d38e4aabb327273de
Later on, long-term (1 year) HSTS was enabled, and Wikimedia projects were added to browser HSTS pre-load lists.
Wikimedia routinely increases security by removing support for older security algorithms and protocols, following the advise and progress of the major browser vendors and the global security community. Users affected by such removals will gradually see increasing occurrences of being redirected to the sec-warning page
, until a time where they will no longer be able to reach Wikimedia websites altogether. The policy for this is documented on wikitech:HTTPS
- General links:
- ↑ Jimmy Wales’ tweet, see the linked image leaked from a "top secret" document.
- ↑ "Wikitech-l: HTTPS for logged in users delayed. New date: August 28"
Last edited on 20 March 2021, at 07:14
Content is available under CC BY-SA 3.0
unless otherwise noted.