wiki

Changes

GC HTTPS Web Server Config (view source)

Revision as of 11:24, 30 September 2019

880 bytes added ,  11:24, 30 September 2019
no edit summary
Line 10: Line 10:     
Departments who have retained responsibility for management of network architecture are recommended to review CSE guidance in setting up external web application servers: Baseline Security Requirements for Network Security Zones in the Government of Canada (https://www.cse-cst.gc.ca/en/node/268/html/15236)
 
Departments who have retained responsibility for management of network architecture are recommended to review CSE guidance in setting up external web application servers: Baseline Security Requirements for Network Security Zones in the Government of Canada (https://www.cse-cst.gc.ca/en/node/268/html/15236)
 +
<br><br>
 +
 +
==Redirect Domains==
 +
Many domains are currently in use across the GC as a means to provide easy access to specific pages to users, for marketing purposes, or as a proactive measure to protect against phishing and cybersquatting (the act of registering domains you don't intend to actually use, with the hopes of selling for profit).  When a specific domain directs users to another domain, they are considered redirect domains.
 +
<br><br>
 +
For a redirect domain to be ITPIN compliant, they need to be secured prior to permanent redirection to the eventual (secure) destination domain. Since each URL has to resolve at the server before being redirected, they are still open to manipulation if HTTP.  When a domain isn't properly secured internally first, it is impossible to provide an HSTS header for that domain, or achieve compliance against cipher and protocol requirements to be used.
 +
<br><br>
 +
For each of the redirected URLs, configuration should:
 +
 +
# first be permanently redirected to a secure version of itself, with HSTS enabled (http://domain-A --(301)--> https://domain-A (with HSTS)); and then
 +
# permanently be redirected (301) to the HTTPS version of the destination site, with HSTS established there as well (https://domain-A --(301)--> https://final-domain (with HSTS))
 +
 +
Visitors will only ever get the double redirect once due to HSTS. In setting up your certificate for your primary site, you can use the Subject Alternative Name (SAN) field to include all of your pointed URLs, rather than having to get certificates for each one.  If necessary, I’d recommend looking at Let’s Encrypt (https://letsencrypt.org/) as a source of free automated certs that provide for a large number of SANs.
 +
<br><br>
 +
'''Note:''' when redirecting to Canada.ca, or another major GC platform you may not/do not have control over, the configuration of the eventual domain is not your responsibility, nor will the results for that domain be reflected in your domain results.  Each domain must be configured appropriately to reach full compliance.
 +
<br><br>
 +
Additional References:
 +
# [https://www.htaccessredirect.net .htaccess Generator]
 +
# [https://github.com/cisagov/pshtt#domain-and-redirect-info CISAGOV-pshtt (Github)] - fully explains redirects, defaults vs. enforces HTTPS measurement by domain-scan
 
<br>
 
<br>
   Line 17: Line 36:  
Departments should choose TLS cipher suites using ephemeral Diffie-Hellman (DH) and ephemeral Elliptic Curve Diffie-Hellman (ECDH) (those with DHE or ECDHE specified in the cipher suite name) since they provide perfect forward secrecy. When using a cipher suite that provides perfect forward secrecy, the compromise of a long-term private key used in deriving a subsequent session key does not cause the compromise of prior session keys.
 
Departments should choose TLS cipher suites using ephemeral Diffie-Hellman (DH) and ephemeral Elliptic Curve Diffie-Hellman (ECDH) (those with DHE or ECDHE specified in the cipher suite name) since they provide perfect forward secrecy. When using a cipher suite that provides perfect forward secrecy, the compromise of a long-term private key used in deriving a subsequent session key does not cause the compromise of prior session keys.
 
<br>
 
<br>
 +
===About Cipher Suites===
 +
A cipher suite is a defined set of algorithms used to secure network connections between two end points (e.g.: user client and server). In the TLS handshake, cipher suites are presented by both the client and server as a means to agree on a communications scheme, and determine a common code to use.  If the two end points can't decide on a cipher suite to use (incompatible lists), no connection will be made.
 +
<br><br>
 +
TLS 1.2 cipher suites include an initial key exchange algorithm, a bulk/message encryption algorithm, and a message authentication code, as in the example here: <code>'''TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384'''</code>
 +
<br><br>
 +
The meaning of this name is:
 +
* ''TLS'' defines the protocol that this cipher suite is for; it will usually be TLS.
 +
* ''ECDHE_ECDSA'' indicates the key exchange algorithm being used. The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake.
 +
* ''AES_256_GCM'' indicates the block cipher being used to encrypt the message stream, together with the block cipher mode of operation.
 +
* ''SHA384'' indicates the message authentication algorithm which is used to authenticate a message.
 +
 
===Secure configuration advice recommendations===
 
===Secure configuration advice recommendations===
 
In general, when configuring servers:
 
In general, when configuring servers:
Line 25: Line 55:  
For details on the TLS handshake, see [https://tls.ulfheim.net/ The Illustrated TLS Connection].
 
For details on the TLS handshake, see [https://tls.ulfheim.net/ The Illustrated TLS Connection].
 
<br><br>
 
<br><br>
−
In the following table, the first column lists all ciphers which satisfy the cryptographic guidance provided in ITSP.40.111.  It is recommended that servers be configured to exclusively support the cipher suites listed in the second column, preferring them in the listed order:
+
In the following table, the first column lists all ciphers as found in cryptographic guidance provided in ITSP.40.111.  Departments are recommended to consider configurations that exclusively support the cipher suites listed in the second column, while preparing for CCCS updates to guidance for use of modern cipher suites of the third column (eliminating known vulnerable ciphers, and introducing approved TLS 1.3 cipher suites), preferring them in the listed order:
 
{| class="wikitable" border="1"  
 
{| class="wikitable" border="1"  
 
|-
 
|-
−
! Full ITSP.40.111 Cipher Suite
+
! Full ITSP.40.111 Cipher Suites
−
! Recommended Cipher Suite
+
! Modified ITSP 40.111 Cipher Suites
 +
! Target Cipher Suites (Publication Pending)
 
|- style="vertical-align:top;"
 
|- style="vertical-align:top;"
 
|  
 
|  
Line 112: Line 143:  
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)
 
* TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)
 
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)
 
* TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)
 +
* TLS_AES_256_GCM_SHA384 (5)
 +
* TLS_AES_128_GCM_SHA256 (5)
 +
* TLS_AES_128_CCM_SHA256 (5)
 +
* TLS_AES_128_CCM_8_SHA256 (5)
 +
 +
|
 +
Recommended and prioritized (TLS 1.3):
 +
* TLS_AES_256_GCM_SHA384 (5)
 +
* TLS_AES_128_GCM_SHA256 (5)
 +
* TLS_AES_128_CCM_SHA256 (5)
 +
 +
Recommended and prioritized (TLS 1.2):
 +
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 +
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM
 +
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
 +
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM
 +
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 +
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 +
 +
Sufficient (Exception Use Only) and prioritized (TLS 1.2):
 +
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (6)
 +
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (6)
 +
* TLS_DHE_RSA_WITH_AES_256_CCM (6)
 +
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (6)
 +
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (6)
 +
* TLS_DHE_RSA_WITH_AES_128_CCM (6)
 +
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
 +
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
 +
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
 +
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
 +
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (6)
 +
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (6)
    
|}
 
|}
Line 121: Line 184:  
* (3) While presently included in CSE guidance, the use of 3DES is not recommended in the context of HTTPS.
 
* (3) While presently included in CSE guidance, the use of 3DES is not recommended in the context of HTTPS.
 
* (4) Mandatory cipher suite for TLS 1.2 as specified in [https://tools.ietf.org/html/rfc5246#page-65 RFC 5246]
 
* (4) Mandatory cipher suite for TLS 1.2 as specified in [https://tools.ietf.org/html/rfc5246#page-65 RFC 5246]
 +
* (5) Approved TLS 1.3 cipher suite, as specified in [https://tools.ietf.org/html/rfc8446 RFC 8446]. Note: The use of TLS_CHACHA20_POLY1305_SHA256 is not approved for use in the GC at this time. TLS_AES_128_CCM_8_SHA256 has been removed from the target cipher suites list as is no longer recommended for TLS 1.3.
 +
* (6) All Diffie-Hellman (DH/DHE) cipher suites must adhere to CSE guidance to use a minimum 2048-bit key.
 
<br>
 
<br>
   Line 159: Line 224:  
* All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtension message allows various extensions previously sent in clear in the ServerHello to also enjoy confidentiality protection from active attackers.
 
* All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtension message allows various extensions previously sent in clear in the ServerHello to also enjoy confidentiality protection from active attackers.
 
* The key derivation functions have been re-designed.  The new design allows easier analysis by cryptographers due to their improved key separation properties.  The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.
 
* The key derivation functions have been re-designed.  The new design allows easier analysis by cryptographers due to their improved key separation properties.  The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.
−
* The handshake state machine has been significantly restructured to be more consistent and to remove superfluous messages such as ChangeCipherSpec (except when needed for middlebox compatibility).
   
* Elliptic curve algorithms are now in the base spec and new signature algorithms. Recommended curve algorithms are found in the table below.
 
* Elliptic curve algorithms are now in the base spec and new signature algorithms. Recommended curve algorithms are found in the table below.
 
* The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation.  
 
* The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation.  
−
* Session resumption with and without server-side state as well as the Pre-Shared Key (PSK)-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange.
+
* Session resumption with and without server-side state as well as the Pre-Shared Key (PSK)-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange. Where non-PSK
 
* Updated references to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).
 
* Updated references to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).
 
<br />
 
<br />
Line 168: Line 232:  
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! Recommended TLS 1.3 Supported Groups !! RFC Details
+
! Recommended TLS 1.3 Supported Groups !! RFC Reference
 
|-
 
|-
 
| secp256r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]
 
| secp256r1 || [https://tools.ietf.org/html/rfc8422 RFC 8422]
Line 186: Line 250:  
| ffdhe8192 || [https://tools.ietf.org/html/rfc7919 RFC 7919]
 
| ffdhe8192 || [https://tools.ietf.org/html/rfc7919 RFC 7919]
 
|}
 
|}
−
 
+
<br />
 +
The following list of TLS 1.3 signature algorithms conforms with ITSP.40.111:
 +
<br />
 +
{| class="wikitable"
 +
|-
 +
! Recommended TLS 1.3 Signature Algorithms !! RFC Reference
 +
|-
 +
| ecdsa_secp256r1_sha256 (0x0403)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]
 +
|-
 +
| ecdsa_secp384r1_sha384 (0x0503)|| [https://tools.ietf.org/html/rfc8446 RFC 8446]
 +
|-
 +
| ecdsa_secp521r1_sha512 (0x0603)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]
 +
|-
 +
| rsa_pss_pss_sha256 (0x0809)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]
 +
|-
 +
| rsa_pss_pss_sha384 (0x080a)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]
 +
|-
 +
| rsa_pss_pss_sha512 (0x080b)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]
 +
|-
 +
| rsa_pss_rsae_sha256 (0x0804)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]
 +
|-
 +
| rsa_pss_rsae_sha384 (0x0805)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]
 +
|-
 +
| rsa_pss_rsae_sha512 (0x0806)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]
 +
|-
 +
| rsa_pkcs1_sha256 (0x0401)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]
 +
|-
 +
| rsa_pkcs1_sha384 (0x0501)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]
 +
|-
 +
| rsa_pkcs1_sha512 (0x0601)|| [https://tools.ietf.org/html/rfc8446#section-4.2.3 RFC 8446]
 +
|}
 
<br />
 
<br />
 
For a complete list of major differences, see the [https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Transport Layer Security (TLS) Protocol Version 1.3 specification], section 1.3.
 
For a complete list of major differences, see the [https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Transport Layer Security (TLS) Protocol Version 1.3 specification], section 1.3.
 
<br /><br />
 
<br /><br />
   −
===Load Balancing and Reverse Proxies===
+
=== Web Server Configuration Templates ===
−
Load balancers and reverse proxy servers are often implement with TLS offloading or termination capabilities, and thus should be included in scope of HTTPS activities.  All endpoints should be adequately configured to meet ITPIN requirements.
+
For example templates of popular Web Server Configurations [[GC HTTPS Everywhere - Web Server Configurations|click here]]!
−
<br><br>
+
 
−
For device specific configuration guidelines, refer to your device manual.
     −
<br>
      
===Testing===
 
===Testing===
Line 221: Line 313:  
* [https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility Mozilla Security/Server Side TLS]
 
* [https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility Mozilla Security/Server Side TLS]
 
* [https://infosec.mozilla.org/guidelines/web_security Mozilla web security general reference]
 
* [https://infosec.mozilla.org/guidelines/web_security Mozilla web security general reference]
 +
* [https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls Transport Layer Security (TLS) best practices with the .NET Framework]
    
In Mozilla’s advice on Server Side TLS, several TLS configurations are described (‘Modern’, ‘Intermediate’, and ‘Old’) that refer to some of the 'best' security settings possible, depending on the versions of the browsers that need to be supported. Supporting the ‘Old’ profile is risky and should be avoided, as it would mean supporting the insecure SSL protocol.
 
In Mozilla’s advice on Server Side TLS, several TLS configurations are described (‘Modern’, ‘Intermediate’, and ‘Old’) that refer to some of the 'best' security settings possible, depending on the versions of the browsers that need to be supported. Supporting the ‘Old’ profile is risky and should be avoided, as it would mean supporting the insecure SSL protocol.
   −
<br>
     −
==HTTP Strict Transport Security (HSTS)==
+
<references />
−
HSTS is a simple and widely supported standard to protect visitors by ensuring that their browsers always connect to a website over HTTPS. HSTS exists to remove the need for the common, insecure practice of redirecting users from http:// to https:// URLs.
  −
<br><br>
  −
HSTS is also highly valuable as an organizational forcing function and compliance mechanism. When a domain owner sets an HSTS policy on its base domain with <code>includeSubDomains</code> and <code>preload</code>, the domain owner is saying '"Every part of our web infrastructure is HTTPS, and always will be."'
  −
<br><br>
  −
When a browser knows that a domain has enabled HSTS, it does two things:
  −
* Always uses an https:// connection, even when clicking on an http:// link or after typing a domain into the location bar without specifying a protocol.
  −
* Removes the ability for users to click through warnings about invalid certificates
  −
<br>
  −
In its simplest form, the policy tells a browser to enable HSTS for that exact domain or subdomain, and to remember it for a given number of seconds: <code>Strict-Transport-Security: max-age=31536000;</code> (1 year)
  −
<br><br>
  −
In its strongest and recommended form, the HSTS policy includes all subdomains, and indicates a willingness to be “preloaded” into browsers, pre-empting the need to visit via unsecure connection first:<code>Strict-Transport-Security: max-age=31536000; includeSubDomains; preload</code>
  −
<br><br>
  −
When moving to HSTS, bear in mind:
  −
* The policy should be deployed at <nowiki>https://domain.gc.ca</nowiki>, not <nowiki>https://www.domain.gc.ca</nowiki>.
  −
* All subdomains associated with the parent domain must be fully ready for HTTPS, e.g.: eliminating mixed content. (They do not have to each have their own HSTS policy.)
  −
* When starting with <code>inclSubDomains</code>, it is best to use a very short <code>max-age</code> time (e.g. 5 minutes - 300s) until you are sure your sub-domains are all fully compliant.
  −
<br>
  −
To enable HTTP Strict Transport Security (HSTS) to help the browser secure connections to your service; at least the first of the following two steps should be take, with <code>preload</code> '''only when ready''':
  −
* add the Strict-Transport-Security HTTP header when the site is accessed over HTTPS - this instructs the browser to only request the HTTPS version in future (until the expiration time in the header elapses)
  −
* add your sites to the HSTS preload lists which modern browsers use to automatically redirect HTTP traffic to HTTPS (Chrome’s preload list is included in many of the other browsers’ lists)
  −
<br>
  −
When ready to preload a domain, departments' web teams are recommended to contact their IT Security teams for a review, prior to submitting the domain to the [https://hstspreload.org/ preload list], to ensure it meets the following requirements:
  −
* HTTPS is enabled on the site's root domain (e.g. <nowiki>https://domain.gc.ca</nowiki>), and all subdomains (e.g. <nowiki>https://www.domain.gc.ca</nowiki>) – especially the www subdomain, if a DNS record for it exists. 'This also includes any subdomains in use solely on intranets'.
  −
* The HSTS policy includes all subdomains (<code>inclSubDomains</code>), with a long <code>max-age</code> (at least 1 year = 31536000s), and a header <code>preload</code> flag to indicate that the domain owner consents to preloading.
  −
* The website redirects from HTTP to HTTPS, at least on the site's root domain.
  −
<br>
  −
'''Note:''' While preloading a domain is an easy proposition, '''backing out of preloaded status is not a simple task'''; be sure you are ready and want to preload your domain prior to doing so. ''Please ensure you read all of the details [https://hstspreload.org/#removal here] before preloading.''  '''GC.ca will not be preloaded until such time that all subdomain (<nowiki>https://domain.gc.ca</nowiki>) sites are HTTPS and have HSTS enabled.'''
  −
<br><br>
  −
Firefox, Safari, Opera, IE11 and Edge also incorporate Chrome’s HSTS preload list, making this feature shared across major browsers.
  −
<br>
  −
===HSTS Configuration for Common Web Servers===
  −
Departments are encouraged to use the Mozilla configuration generator in developing HTST headers, referenced in Section 5, above.
  −
<br>
  −
===HSTS and Cookies===
  −
When locking in the use of HTTPS through HSTS, cookies should be set with the Secure flag.  The scope of the domain and path of the cookies should be set as restrictively as possible. This can help minimize damage from cross-site scripting (XSS) vulnerabilities, as cookies often contain session identifiers or other sensitive information.
  −
* Cookie names may be prepended with <code>__Secure-</code> to prevent cookies from being overwritten by insecure sources;
  −
* <code>__Secure-</code> prefix should be used for all cookies sent from secure origins (such as HTTPS).
  −
<br>
  −
===Additional References===
  −
# [https://tools.ietf.org/html/rfc6797 HSTS Spec (IETF)]
  −
# [https://hstspreload.org/ HSTS Preload]
  −
# [https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet OWASP HSTS Cheat Sheet]
  −
# [https://www.owasp.org/index.php/SecureFlag OWASP Secure Cookie page]
  −
# [http://caniuse.com/#feat=stricttransportsecurity Browser support for HSTS]
  −
# [https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security HSTS web developer documentation maintained by the Mozilla community]
  −
# [https://scotthelme.co.uk/hsts-cheat-sheet/ HSTS Cheat Sheet (Scott Helme)]
 
Retrieved from "https://wiki.gccollab.ca/Special:MobileDiff/8163...12748"