Difference between revisions of "GC HTTPS Web Server Config"

From wiki
Jump to navigation Jump to search
 
(36 intermediate revisions by 2 users not shown)
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)]
 

Latest revision as of 10:24, 30 September 2019

Recommendations

Departments should make use of CSE-approved protocols, as outlined in: CSE’S ITSP.40.062 Guidance on Securely Configuring Network Protocols. Per CSE guidance ITSP.40.062: TLS servers and clients should be configured to use TLS 1.2 as specified in RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 [9]. Older versions of TLS and all versions of Secure Sockets Layer (SSL) should not be used since vulnerabilities exist.

A broad overview of the use of TLS is provided in the draft NIST Securing Web Transactions: TLS Server Certificate Management Special Publication (SP 1800-16 (DRAFT)). Detailed TLS configuration guidance for both servers and clients is similarly provided in NIST Special Publication (SP) 800 52 Rev 1 Guidelines on the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. Note that NIST SP 800-52 Rev 2 draft is available for review, but has yet to be formally published.

Departments are encouraged to make use of the Mozilla server configurator as a means to develop modern configuration scripts, in addition to the tools available at SSL Labs to test public facing web servers for security level and compatibility:

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)

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.

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.

For each of the redirected URLs, configuration should:

  1. first be permanently redirected to a secure version of itself, with HSTS enabled (http://domain-A --(301)--> https://domain-A (with HSTS)); and then
  2. 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.

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.

Additional References:

  1. .htaccess Generator
  2. CISAGOV-pshtt (Github) - fully explains redirects, defaults vs. enforces HTTPS measurement by domain-scan


TLS Cipher Suite Support

Departments should make use of CSE-approved cryptographic algorithms, as outlined in:

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.

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.

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: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

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

In general, when configuring servers:

  • Avoid SHA-1 in the TLS handshake. When configuring TLS 1.2, it is suggested to specify SHA256 or SHA384 for cipher suite simplification and consistency with the hash function used for signature digest. Though there is no known specific vulnerability in the use of SHA-1 as part of the TLS handshake, SHA-1 has been shown to be unacceptably weak for use as a signature algorithm for issued certificates.
  • Avoid RC4. RC4 has never been approved by CSE for the protection of GC information. Modern browsers no longer support RC4-based cipher suites, and servers should no longer need to be configured to support RC4.
  • Servers should be configured to ensure that the server and client ephemeral key-pairs (see PFS below) satisfy the key length requirements specified in ITSP.40.111.


For details on the TLS handshake, see The Illustrated TLS Connection.

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:

Full ITSP.40.111 Cipher Suites Modified ITSP 40.111 Cipher Suites Target Cipher Suites (Publication Pending)
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;
  • TLS_ECDHE_ECDSA_WITH_AES_128_CCM;
  • TLS_ECDHE_ECDSA_WITH_AES_256_CCM;
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;
  • TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;
  • TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;
  • TLS_DHE_RSA_WITH_AES_128_CCM;
  • TLS_DHE_RSA_WITH_AES_256_CCM;
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;
  • TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)
  • TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)
  • TLS_RSA_WITH_AES_128_GCM_SHA256; (2)
  • TLS_RSA_WITH_AES_256_GCM_SHA384; (2)
  • TLS_RSA_WITH_AES_128_CCM; (2)
  • TLS_RSA_WITH_AES_256_CCM; (2)
  • TLS_RSA_WITH_AES_128_CBC_SHA256; (2)
  • TLS_RSA_WITH_AES_256_CBC_SHA256; (2)
  • TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)
  • TLS_RSA_WITH_AES_256_CBC_SHA; (1)(2)
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)
  • TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA; (1)(3)
  • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA; (1)(3)
  • TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA; (1)(3) and
  • TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA. (1)(3)
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;
  • TLS_ECDHE_ECDSA_WITH_AES_128_CCM;
  • TLS_ECDHE_ECDSA_WITH_AES_256_CCM;
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA; (1)
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA; (1)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; (1)
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; (1)
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;
  • TLS_DHE_DSS_WITH_AES_128_GCM_SHA256;
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;
  • TLS_DHE_DSS_WITH_AES_256_GCM_SHA384;
  • TLS_DHE_RSA_WITH_AES_128_CCM;
  • TLS_DHE_RSA_WITH_AES_256_CCM;
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;
  • TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA; (1)
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA; (1)
  • TLS_DHE_DSS_WITH_AES_256_CBC_SHA; (1)
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA; (1)
  • TLS_RSA_WITH_AES_128_GCM_SHA256; (2)
  • TLS_RSA_WITH_AES_256_GCM_SHA384; (2)
  • TLS_RSA_WITH_AES_128_CCM; (2)
  • TLS_RSA_WITH_AES_256_CCM; (2)
  • TLS_RSA_WITH_AES_128_CBC_SHA256; (2)
  • TLS_RSA_WITH_AES_256_CBC_SHA256; (2)
  • TLS_RSA_WITH_AES_128_CBC_SHA; (1)(2)(4)
  • 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)


Notes:

  • (1) Departments are recommended to avoid ciphers suites using SHA-1 in the handshake for simplicity’s sake, to align with PKI guidance to use SHA-256 signed certificates.
  • (2) Departments are recommended to avoid using non-ephemeral cipher suites as much as possible, for future proofing (not included in TLS 1.3), and to ensure forward secrecy.
  • (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 RFC 5246
  • (5) Approved TLS 1.3 cipher suite, as specified in 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.


Perfect Forward Secrecy (PFS)

Forward secrecy protects information sent over an encrypted HTTPS connection now from being decrypted later, even if the server’s private key is later compromised, through the use of different public/private key pairs each session. In TLS, forward secrecy is provided by choosing cipher suites that include the DHE and ECDHE key exchanges.

Departments should make use of CSE-approved DHE and ECDHE cipher suites that support Perfect Forward Secrecy, as strongly recommended in:

Note: TLS 1.3, the newest version of TLS, requires new connections to use forward secrecy by removing support for static RSA and DH key exchange.

  • The GC HTTPS dashboard for all external domains will note when a domain offers little or no forward secrecy.
  • cyber.gc.ca is configured to offer robust forward secrecy.


HTTP/2

HTTP/2 (finalized in 2015) is a backwards-compatible update to HTTP/1.1 (finalized in 1999) that is optimized for the modern web.

HTTP/2 includes many features that can drastically speed up website performance, and emerged from the advancements Google demonstrated with SPDY in 2009.

While HTTP/2 does not require the use of encryption in its formal spec, every major browser that has implemented HTTP/2 has only implemented support for encrypted connections, and no major browser is working on support for HTTP/2 over unencrypted connections.

This means that in practice, the major performance benefits of HTTP/2 first require the use of HTTPS.


TLS 1.3

Note: the use of TLS 1.3 must be accompanied with the understanding of how it impacts your security architecture, and use of network appliances. TLS 1.3 mandates an end-to-end secure connection, and may force changes in infrastructure and TLS termination points.

Forthcoming updates to the GC recommended cipher suites list will prioritize TLS 1.3 cipher suites over TLS 1.2.

TLS 1.3 differs from TLS 1.2 and earlier versions of TLS in several substantial ways, in addition to the cipher suite changes; these changes result in it not being directly compatible with the earlier versions of TLS. The following is a list of the major functional differences between TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there are many minor differences. [1]

  • The list of supported symmetric algorithms has been pruned of all algorithms that are considered legacy. Those that remain all use Authenticated Encryption with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with the key derivation function and HMAC.
  • A 0-RTT mode was added, saving a round-trip at connection setup for some application data, at the cost of certain security properties. Admins should be aware of the security implications of 0-RTT, detailed in RFC 8446 Appendix E.5.
  • Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
  • 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.
  • 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.
  • 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).


Recommended TLS 1.3 Supported Groups RFC Reference
secp256r1 RFC 8422
secp384r1 RFC 8422
secp521r1 RFC 8422
ffdhe2048 RFC 7919
ffdhe3072 RFC 7919
ffdhe4096 RFC 7919
ffdhe6144 RFC 7919
ffdhe8192 RFC 7919


The following list of TLS 1.3 signature algorithms conforms with ITSP.40.111:

Recommended TLS 1.3 Signature Algorithms RFC Reference
ecdsa_secp256r1_sha256 (0x0403) RFC 8446
ecdsa_secp384r1_sha384 (0x0503) RFC 8446
ecdsa_secp521r1_sha512 (0x0603) RFC 8446
rsa_pss_pss_sha256 (0x0809) RFC 8446
rsa_pss_pss_sha384 (0x080a) RFC 8446
rsa_pss_pss_sha512 (0x080b) RFC 8446
rsa_pss_rsae_sha256 (0x0804) RFC 8446
rsa_pss_rsae_sha384 (0x0805) RFC 8446
rsa_pss_rsae_sha512 (0x0806) RFC 8446
rsa_pkcs1_sha256 (0x0401) RFC 8446
rsa_pkcs1_sha384 (0x0501) RFC 8446
rsa_pkcs1_sha512 (0x0601) RFC 8446


For a complete list of major differences, see the Transport Layer Security (TLS) Protocol Version 1.3 specification, section 1.3.

Web Server Configuration Templates

For example templates of popular Web Server Configurations click here!


Testing

Given the wide range of configuration options available for TLS, we recommend that you regularly test the configuration of your web servers by running automated scans. There are a number of publicly available tools to help test the TLS configuration of your web or mail server. Some tools you may find useful are:

These scans will identify most common issues and configuration problems. They should not be seen as a replacement for skilled penetration testing of your services, but if you have already used tools such as these to help identify and mitigate common issues, then penetration testers will have more time to spend ensuring there are not more subtle or unique flaws in your service.


Search Engine Optimization (SEO)

In general, migrating to HTTPS improves a website’s own SEO and analytics.

  • As of August 2014, Google uses HTTPS as a ranking signal, which can improve search rankings.
  • Migrating to HTTPS will improve analytics about web traffic referred from HTTPS websites, as referrer information is not passed from HTTPS websites to HTTP websites.

Prior to HSTS taking effect, or preloading your domain, to make the migration as smooth as possible, and avoid taking a SEO ranking hit:

  • If possible, always choose to use a 301 redirect (signals permanent move) to redirect users from http:// to https://. Do not use a 302 redirect (signals temporary move), as this may negatively impact search rankings, since search engines will not formally replace your old HTTP site with HTTPS.
  • Use a canonical link element (<link rel="canonical">) to inform search engines that the “canonical” URL for a website uses https://. Ex: <link rel="canonical" href="https://example.gc.ca/folder/folder2/">


Additional References

There are a number of good guides that provide configuration advice for HTTPS:

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.


  1. ↑ Internet Engineering Task Force (IETF) TLS 1.3 Internet-Draft
Retrieved from "https://wiki.gccollab.ca/index.php?title=GC_HTTPS_Web_Server_Config&oldid=12748"