Important: The GCConnex decommission will not affect GCCollab or GCWiki. Thank you and happy collaborating!
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:
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:
- 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.
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:
- .htaccess Generator
- 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:
- 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.
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) |
|---|---|---|
|
|
Recommended and prioritized (TLS 1.3):
Recommended and prioritized (TLS 1.2):
Sufficient (Exception Use Only) and prioritized (TLS 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
- (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.
- 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. [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:
- Qualys - SSL/TLS Deployment Best Practices
- Google - Webmasters: Secure Your Site with HTTPS
- Mozilla Security/Server Side TLS
- Mozilla web security general reference
- 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.
- ↑ Internet Engineering Task Force (IETF) TLS 1.3 Internet-Draft
