You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

HTTPS: Difference between revisions

From Wikitech-static
Jump to navigation Jump to search
imported>HaeB
imported>BBlack
 
(12 intermediate revisions by 8 users not shown)
Line 1: Line 1:
'''[[w:HTTPS|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 [[w:Man-in-the-middle_attack|man-in-the-middle attacks]]. This page and its related subpages attempt to document the current best practices and standards for both server and client side protections.
{{Navigation Wikimedia infrastructure|expand=traffic}}
'''[[w:HTTPS|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 [[w:Man-in-the-middle_attack|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 =
== 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 HTTP[S] sites and services under Wikimedia control ==
== 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. Most of these (and many related issues) can usually be caught by auditing with external tools such as https://www.ssllabs.com/ssltest/ .  If you're not getting an A+ there, there's probably an issue with policies below:
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.


* '''HTTPS enabled''' - ...with a minimum allowed protocol version of TLSv1.0 (no SSLv2/SSLv3), and supporting at least version TLSv1.2 (TLSv1.3 still experimental)
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:
* '''Good Certs''' - Certificates must validate correctly in all common browsers, must send chain certs attaching them to known roots, and must meet current crypto minimum best practices (currently RSA:2048 + SHA-256).
 
* '''Decent Ciphers''' - Must not offer ancient/broken ciphers, which currently means any of the "export-grade" ciphers as well as anything using RC4 or MD5.  The minimum (least-secure) reasonable ciphers allowed are AES128-SHA and DES-CBC3-SHA.  Must offer at least one modern Forward Secret AEAD cipher, e.g. ECDHE-RSA-AES128-GCM-SHA256, which is prioritized higher than legacy ciphers if cipher selection is done by the server. Should prioritize modern ciphers over older ones in general.
* '''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.
* '''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 [[:en:HTTP_Strict_Transport_Security|HSTS]] header with a minimum max-age value of 1 year, which includes subdomains and allows preloading.  Example: <code>Strict-Transport-Security: max-age=31536000; includeSubDomains; preload</code>.
* '''HSTS''' - All HTTPS responses must include an [[:en:HTTP_Strict_Transport_Security|HSTS]] header with a minimum max-age value of 1 year, which includes sub-domains and allows preloading.  Example: <code>Strict-Transport-Security: max-age=31536000; includeSubDomains; preload</code>.
 
== Certificate Issuance and Renewal ==
 
Most of our certificates are automated via [[Acme-chief]] using certs from [https://letsencrypt.org/ Let's Encrypt].
 
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 [[:en:Online_Certificate_Status_Protocol|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 [https://digicert.com 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 Foundation's canonical domainnames ==
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.
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.
Line 22: Line 34:
* wiktionary.org
* wiktionary.org
* wikiquote.org
* wikiquote.org
* wikifunctions.org
* wikibooks.org
* wikibooks.org
* wikisource.org
* wikisource.org
Line 33: Line 46:
* w.wiki
* w.wiki


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:
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 nameservers (currently <code>ns0.wikimedia.org</code>, <code>ns1.wikimedia.org</code>, and <code>ns2.wikimedia.org</code>).
* Must be registered to the Wikimedia Foundation, and must be delegated by the registrar directly to the Foundation's name servers (currently <code>ns0.wikimedia.org</code>, <code>ns1.wikimedia.org</code>, and <code>ns2.wikimedia.org</code>).
* Must have valid [[:en:DNS_Certification_Authority_Authorization|CAA]] records denoting one or more legitimate certificate vendors designated by the Operations team.
* Must have valid [[:en:DNS_Certification_Authority_Authorization|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/ .
* Must be submitted to (and eventually successfully included in) the STS preload list maintained by the Chromium project at https://hstspreload.org/ .


= Related Information =
== Related information ==


* [[HTTPS/Browser Recommendations]] - Browser security recommendations aimed at end-users.
* [[HTTPS/Browser Recommendations]] - Browser security recommendations aimed at end-users.
* [[HTTPS/Domains]] - Some tracking/auditing on minor non-standard sites that are in-scope.
* [[HTTPS/Domains]] - Some tracking/auditing on minor non-standard sites that are in-scope.
* [https://grafana.wikimedia.org/dashboard/db/tls-ciphers TLS cipher suite stats dashboard]
* [https://grafana.wikimedia.org/dashboard/db/tls-ciphersuite-explorer TLS cipher suite stats dashboard]
* [https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/ Blog announcement of our switch to HTTPS-only back in mid-2015]
* [https://diff.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/ Blog announcement of our switch to HTTPS-only back in mid-2015]
* {{phabricator|T104681}} - Phabricator task tracking the long tail of securing minor sites in the wake of the switch above for major projects.
* {{phabricator|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|HTTPS/Archived-Pre-2015]] - Old outdated information from this page, mostly predating the above.
* [[HTTPS/Archived-Pre-2015|HTTPS/Archived-Pre-2015]] - Old outdated information from this page, mostly predating the above.
* The [[X-Analytics]] header contains a "https" field.
* The [[X-Analytics]] header contains a "https" field.
* [[Cergen#Cheatsheet|Creating TLS certificates with cergen (for envoyproxy et al)]]
* [[User:Giuseppe_Lavagetto/Add_Tls_On_Kubernetes|Adding TLS on Kubernetes]]
* [[User:Jbond/Encryption]]
* [[mw:Manual:HTTPS]]
[[Category:TLS]]
__NOTOC__

Latest revision as of 13:52, 4 November 2022

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

Most of our certificates are automated via Acme-chief using certs from Let's Encrypt.

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:

  • wikipedia.org
  • wikimedia.org
  • wiktionary.org
  • wikiquote.org
  • wikifunctions.org
  • wikibooks.org
  • wikisource.org
  • wikinews.org
  • wikiversity.org
  • wikidata.org
  • wikivoyage.org
  • wikimediafoundation.org
  • mediawiki.org
  • wmfusercontent.org
  • w.wiki

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 ns0.wikimedia.org, ns1.wikimedia.org, and ns2.wikimedia.org).
  • 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/ .

Related information