GC HTTPS Web Server Config

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:

• Mozilla SSL Config Generator
• SSL Labs SSL Test

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)

TLS Cipher Suite Support

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

• CSE’s ITSP.40.111 Cryptographic Algorithms for Unclassified, Protected A, and Protected B Information

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.

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

Full ITSP.40.111 Cipher Suite

Recommended Cipher Suite

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)

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

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:

• CSE’S Guidance on Securely Configuring Network Protocols

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.

• HTTP/2 Working Group FAQ
• RFC 7540, the final spec

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.

• 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.

Load Balancing and Reverse Proxies

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 device specific configuration guidelines, refer to your device manual.

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:

• Qualys SSL Server Test
• Hardenize domain analysis tool

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:

• Qualys - SSL/TLS Deployment Best Practices
• Google - Webmasters: Secure Your Site with HTTPS
• Mozilla Security/Server Side TLS
• Mozilla web security general reference

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.

HTTP Strict Transport Security (HSTS)

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.

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 includeSubDomains and preload, the domain owner is saying '"Every part of our web infrastructure is HTTPS, and always will be."'

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

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: Strict-Transport-Security: max-age=31536000; (1 year)

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:Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

When moving to HSTS, bear in mind:

• The policy should be deployed at https://domain.gc.ca, not https://www.domain.gc.ca.
• 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 inclSubDomains, it is best to use a very short max-age time (e.g. 5 minutes - 300s) until you are sure your sub-domains are all fully compliant.

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 preload 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)

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 preload list, to ensure it meets the following requirements:

• HTTPS is enabled on the site's root domain (e.g. https://domain.gc.ca), and all subdomains (e.g. https://www.domain.gc.ca) – 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 (inclSubDomains), with a long max-age (at least 1 year = 31536000s), and a header preload 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.

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 here before preloading. GC.ca will not be preloaded until such time that all subdomain (https://domain.gc.ca) sites are HTTPS and have HSTS enabled.

Firefox, Safari, Opera, IE11 and Edge also incorporate Chrome’s HSTS preload list, making this feature shared across major browsers.

HSTS Configuration for Common Web Servers

Departments are encouraged to use the Mozilla configuration generator in developing HTST headers, referenced in Section 5, above.

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 __Secure- to prevent cookies from being overwritten by insecure sources;
• __Secure- prefix should be used for all cookies sent from secure origins (such as HTTPS).

Additional References

1. HSTS Spec (IETF)
2. HSTS Preload
3. OWASP HSTS Cheat Sheet
4. OWASP Secure Cookie page
5. Browser support for HSTS
6. HSTS web developer documentation maintained by the Mozilla community
7. HSTS Cheat Sheet (Scott Helme)