802
edits
Changes
GC HTTPS Web Server Config (view source)
Revision as of 11:24, 30 September 2019
, 11:24, 30 September 2019no edit summary
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>
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:
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
! ITSP 40.111 Modified Cipher Suite
! Modified ITSP 40.111 Cipher Suites
! Target Cipher Suite (06/01/19)
! Target Cipher Suites (Publication Pending)
|- style="vertical-align:top;"
|- style="vertical-align:top;"
|
|
* TLS_AES_128_CCM_SHA256 (5)
* TLS_AES_128_CCM_SHA256 (5)
* TLS_AES_128_CCM_8_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_GCM_SHA384
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM
* TLS_ECDHE_ECDSA_WITH_AES_256_CCM
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
Sufficient (Exception Use Only) and prioritized (TLS 1.2):
* TLS_DHE_RSA_WITH_AES_256_CCM
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (6)
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (6)
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
* TLS_DHE_RSA_WITH_AES_256_CCM (6)
* TLS_DHE_RSA_WITH_AES_128_CCM
* 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)
|}
|}
* (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.
* (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>
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 />
=== Web Server Configuration Templates ===
For example templates of popular Web Server Configurations [[GC HTTPS Everywhere - Web Server Configurations|click here]]!
* [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>
<references />