Difference between revisions of "GC HTTPS Web Server Config"
(Created page with " ==Recommendations== Departments should make use of CSE-approved protocols, as outlined in: CSE’S ITSP.40.062 [https://www.cse-cst.gc.ca/en/publication/list/Security-Protoco...") |
(No difference)
|
Revision as of 12:29, 23 October 2018
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. 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)
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.
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 |
|---|---|
|
|
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:
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.
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:
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 shortmax-agetime (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 longmax-age(at least 1 year = 31536000s), and a headerpreloadflag 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).
