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.
In other languages: العربية (ar) English (en)فارسی (fa) français (fr) italiano (it) 日本語 (ja)Nederlands (nl) español (es) português (pt)русский (ru) 中文 (zh) Tiếng Việt (vi) [edit]
HTTPS (HTTP Secure) is a web protocol that improves the security of communication between the user and the server. With it enabled:
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.[1] 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 ( 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.
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 Pywikibot, please update to the latest version (More technical details: [1],[2]) and read this mailing list post for more information.
Various problems
Redirects to sec-warning
When Wikimedia is deprecating outdated security protocols, users may be redirected increasingly often to a page titled: Your Browser's Connection Security is Outdated. This means that you should update your browser Browser and/or Operating System because otherwise you will soon not be able to connect to Wikimedia websites.
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.
Missing images
If images are missing, check if you can see for instance this thumb image from Commons. If you get a certificate warning please see the next section about this.
Missing scripts
If you had custom scripts that you retrieved by calling a function loadJS or importScriptUri, 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: or 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:
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 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
This deployment of HTTPS was described in Wikimedia engineering reports from May 2011 to December 2011.
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.[2]) 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:
Later on, long-term (1 year) HSTS was enabled, and Wikimedia projects were added to browser HSTS pre-load lists.
Rolling improvements
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.
  1. Jimmy Wales’ tweet, see the linked image leaked from a "top secret" document.
  2. "Wikitech-l: HTTPS for logged in users delayed. New date: August 28"
See also
Persian Wikipedia stance
Last edited on 20 March 2021, at 07:14
Content is available under CC BY-SA 3.0 unless otherwise noted.
Privacy policy
Terms of Use
HomeRandomLog inSettingsDonateAbout MetaDisclaimers