User:Apking/Web Security Guidelines: Difference between revisions

A bunch of minor fixes with kang's feedback
(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, all systems must use encrypted TLS connections for their network communications.  Support and use of TLS is mandatory for all new systems, and existing systems are expected to add support for exclusive TLS as soon as possible.
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]]. Very few sites should require this compatibility level, and use of this compatibility level should be noted in your risk assessment.
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 also acceptable.  Note that once this value is set, the site must continue to support HTTPS until the expiry time has been reached.
<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 six months
<pre># Only connect to this site via HTTPS for the next year (recommended)
Strict-Transport-Security: max-age=15768000</pre>
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 from http to https with nginx
<pre># Redirect all incoming http requests to the same site and URI on https, using nginx
server {
server {
   listen 80;
   listen 80;
  server_name site.mozilla.org;


   return 301 https://$server_name$request_uri;
   return 301 https://$host$request_uri;
}</pre>
}</pre>


<pre># Redirect from http to https with Apache
<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.
Anti-spam team, Confirmed users
99

edits