263
edits
Changes
Jump to navigation
Jump to search
Line 248:
Line 248: − − ==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. − <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)]
GC HTTPS Web Server Config (view source)
Revision as of 16:20, 20 February 2019
, 16:20, 20 February 2019no edit summary
<br>
<br>
