Anti-spam team, Confirmed users
99
edits
(Fix the Guideline column to be resortable) |
(A bunch of minor fixes with kang's feedback) |
||
Line 2: | Line 2: | ||
<table> | <table> | ||
<tr> | <tr> | ||
<td style="white-space: nowrap;">__TOC__</td> | <td class="toclimit-1" style="white-space: nowrap;">__TOC__</td> | ||
<td style="vertical-align: top; padding-left: 1em;">The goal of this document is to help operational teams with creating secure web applications. All Mozilla sites and deployments are expected to follow the recommendations below. | <td style="vertical-align: top; padding-left: 1em;">The goal of this document is to help operational teams with creating secure web applications. All Mozilla sites and deployments are expected to follow the recommendations below. | ||
Line 16: | Line 16: | ||
== HTTPS == | == HTTPS == | ||
Transport Layer Security (TLS/SSL) provides assurances about the confidentiality, authentication, and integrity of all communications both inside and outside of Mozilla. To protect our users and networked systems, | Transport Layer Security (TLS/SSL) provides assurances about the confidentiality, authentication, and integrity of all communications both inside and outside of Mozilla. To protect our users and networked systems, the support and use of encrypted communications using TLS is mandatory for all systems. | ||
Websites or API endpoints that only communicate with modern browsers and systems should use the [[Security/Server Side TLS#Modern compatibility|Mozilla modern TLS configuration]]. | Websites or API endpoints that only communicate with modern browsers and systems should use the [[Security/Server Side TLS#Modern compatibility|Mozilla modern TLS configuration]]. | ||
Line 22: | Line 22: | ||
Websites intended for general public consumption should use the [[Security/Server Side TLS#Intermediate compatibility (default)|Mozilla intermediate TLS configuration]]. | Websites intended for general public consumption should use the [[Security/Server Side TLS#Intermediate compatibility (default)|Mozilla intermediate TLS configuration]]. | ||
Websites that require backwards compatibility with extremely old browsers may use the [[Security/Server Side TLS#Old backward compatibility|Mozilla backwards compatible TLS configuration]]. | Websites that require backwards compatibility with extremely old browsers and operating systems may use the [[Security/Server Side TLS#Old backward compatibility|Mozilla backwards compatible TLS configuration]]. This is not recommended, and use of this compatibility level should be noted in your risk assessment. | ||
=== Compatibility === | === Compatibility === | ||
Line 60: | Line 60: | ||
* <tt>preload:</tt> whether the site should be included in the [https://hstspreload.appspot.com/ HSTS preload list] | * <tt>preload:</tt> whether the site should be included in the [https://hstspreload.appspot.com/ HSTS preload list] | ||
<tt>max-age</tt> must be set to a minimum of six months (15768000), but longer periods such as one year (31536000) or longer are | <tt>max-age</tt> must be set to a minimum of six months (15768000), but longer periods such as one year (31536000) or longer are recommended. Note that once this value is set, the site must continue to support HTTPS until the expiry time has been reached. | ||
<tt>includeSubDomains</tt> notifies the browser that all subdomains of the current origin should also be upgraded via HSTS. For example, setting <tt>includeSubDomains</tt> on <tt>domain.mozilla.com</tt> will also set it on <tt>host1.domain.mozilla.com</tt> and <tt>host2.domain.mozilla.com</tt>. Extreme care is needed when setting the <tt>includeSubDomains</tt> flag, as it could disable sites on subdomains that don't yet have HTTPS enabled. | <tt>includeSubDomains</tt> notifies the browser that all subdomains of the current origin should also be upgraded via HSTS. For example, setting <tt>includeSubDomains</tt> on <tt>domain.mozilla.com</tt> will also set it on <tt>host1.domain.mozilla.com</tt> and <tt>host2.domain.mozilla.com</tt>. Extreme care is needed when setting the <tt>includeSubDomains</tt> flag, as it could disable sites on subdomains that don't yet have HTTPS enabled. | ||
Line 68: | Line 68: | ||
=== Examples === | === Examples === | ||
<pre># Only connect to this site via HTTPS for the next | <pre># Only connect to this site via HTTPS for the next year (recommended) | ||
Strict-Transport-Security: max-age= | Strict-Transport-Security: max-age=31536000</pre> | ||
<pre># Only connect to this site and subdomains via HTTPS for the next year and also include in the preload list | <pre># Only connect to this site and subdomains via HTTPS for the next year and also include in the preload list | ||
Line 88: | Line 88: | ||
=== Examples === | === Examples === | ||
<pre># Redirect | <pre># Redirect all incoming http requests to the same site and URI on https, using nginx | ||
server { | server { | ||
listen 80; | listen 80; | ||
return 301 https://$ | return 301 https://$host$request_uri; | ||
}</pre> | }</pre> | ||
<pre># Redirect from http to https | <pre># Redirect for site.mozilla.org from http to https, using Apache | ||
<VirtualHost *:80> | <VirtualHost *:80> | ||
ServerName site.mozilla.org | ServerName site.mozilla.org | ||
Line 105: | Line 104: | ||
== HTTP Public Key Pinning == | == HTTP Public Key Pinning == | ||
Maximum risk sites must enable the use of HTTP Public Key Pinning (HPKP). HPKP instructs a user agent to bind a site to specific root certificate authority, intermediate certificate authority, or end-entity public key. This prevents certificate authorities from issuing unauthorized certificates for a given domain that would nevertheless be trusted by the browsers. These fradulent certificates would allow an active attacker to MitM and impersonate a website, intercepting credentials and other sensitive data. | [[Security/Risk management/Rapid Risk Assessment#RRA Risk table (5-10 minutes)|Maximum risk]] sites must enable the use of HTTP Public Key Pinning (HPKP). HPKP instructs a user agent to bind a site to specific root certificate authority, intermediate certificate authority, or end-entity public key. This prevents certificate authorities from issuing unauthorized certificates for a given domain that would nevertheless be trusted by the browsers. These fradulent certificates would allow an active attacker to MitM and impersonate a website, intercepting credentials and other sensitive data. | ||
Due to the risk of knocking yourself off the internet, HPKP must be implemented with extreme care. This includes having backup key pins, testing on a non-production domain, testing with <tt>Public-Key-Pins-Report-Only</tt> and then finally doing initial testing with a very short-lived <tt>max-age</tt> directive. Because of the risk of creating a self-denial-of-service and the very low risk of a fraudulent certificate being issued, it is <em>not recommended</em> for the majority websites to implement HPKP. | Due to the risk of knocking yourself off the internet, HPKP must be implemented with extreme care. This includes having backup key pins, testing on a non-production domain, testing with <tt>Public-Key-Pins-Report-Only</tt> and then finally doing initial testing with a very short-lived <tt>max-age</tt> directive. Because of the risk of creating a self-denial-of-service and the very low risk of a fraudulent certificate being issued, it is <em>not recommended</em> for the majority websites to implement HPKP. |