You are browsing a read-only backup copy of Wikitech. The primary site can be found at wikitech.wikimedia.org
HTTPS (also called HTTP over Transport Layer Security (TLS), HTTP over SSL, and HTTP Secure) is a communications protocol for secure communication over a computer network which is widely used on the Internet. The Wikimedia family of wikis and services use HTTPS encryption to prevent eavesdropping and man-in-the-middle attacks. This page and its related sub-pages attempt to document the current best practices and standards for both server and client side protections.
Current policies and standards
Security standards are constantly updated, and Wikimedia follows these changes as well. When older standards are dropped, this is done gradually and you might see the page https://www.wikipedia.org/sec-warning giving you information about why your browser will not be supported in the future.
For all public-facing Web sites and services under Wikimedia control
These policies and standards apply to all services having hostnames within our canonical domains (see below), even for sites run by third parties on our behalf.
We currently rely on https://www.ssllabs.com/ssltest/ to audit sites for basic TLS security issues. Sites must get an A+ rating there. Failing to reach A+ on that audit can happen for a very long list of reasons detailed in: https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide . A few more-specific issues (or issues that are not explicitly validated at by having an A+) are listed here:
- HTTPS enabled - ...with a minimum allowed protocol version of TLSv1.2 and supporting at least version TLSv1.2.
- Good Certs - Certificates must validate correctly in all common browsers, must send chain certs attaching them to known roots.
- Decent Ciphers - Must offer forward-secret AEAD ciphers (e.g. ECDHE-*-AES128-GCM), should offer only forward-secret ciphers, and should not allow non-AEAD ciphers (e.g. AES CBC modes)
- HTTP service - If available at all, must exist solely for the purpose of redirecting to HTTPS and not serve actual content. Preferred mechanics are that all GET and HEAD requests emit a 301 redirect to the same URL over HTTPS, and all other methods emit a 403 error.
- HSTS - All HTTPS responses must include an HSTS header with a minimum max-age value of 1 year, which includes sub-domains and allows preloading. Example:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.
Certificate Issuance and Renewal
For our most important use-case, which is the "unified" certificate which covers all of the canonical domainnames of the main foundation projects and thus most of our production traffic, we maintain a pair of independently-issued certificates from independent certificate authorities as a defense against renewal issues and/or realtime OCSP outages by the CAs. One of the pair is from our standard LE / Acme-chief automation, and the other is a commercial certificate issued by Digicert. We deploy the LE cert at our US edges and the Digicert cert at our non-US edges, so that both see constant live use and are known-good options in the case that emergency operations require us to switch all edge sites to just one of the two.
For the manual, commercial renewals such as the Digicert certificate above, it's important that a new certificate is aged by a few days (ideally as much as a week) before deployment to avoid rejection by clients with bad clocks as referenced in phab:T196248.
For the Foundation's canonical domain names
While the Foundation may own many other domains for trademark, legal, or project/redirect reasons, there is only one small set which are considered to be the canonical set for our actual projects and content, which are subjected to higher standards.
The current list of canonical domains is:
In addition to the basic per-service standards above, for all services hosted within these domains, the domains themselves must comply with additional policy at the domain level:
- Must be registered to the Wikimedia Foundation, and must be delegated by the registrar directly to the Foundation's name servers (currently
- Must have valid CAA records denoting one or more legitimate certificate vendors designated by the Operations team.
- Must be submitted to (and eventually successfully included in) the STS preload list maintained by the Chromium project at https://hstspreload.org/ .
- HTTPS/Browser Recommendations - Browser security recommendations aimed at end-users.
- HTTPS/Domains - Some tracking/auditing on minor non-standard sites that are in-scope.
- TLS cipher suite stats dashboard
- Blog announcement of our switch to HTTPS-only back in mid-2015
- task T104681 - Phabricator task tracking the long tail of securing minor sites in the wake of the switch above for major projects.
- HTTPS/Archived-Pre-2015 - Old outdated information from this page, mostly predating the above.
- The X-Analytics header contains a "https" field.
- Creating TLS certificates with cergen (for envoyproxy et al)
- Adding TLS on Kubernetes