GC HTTPS HSTS

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
• Note: HSTS headers set on HTTP endpoints are ignored by most browsers due to the potential for malicious headers to be injected, however are recognized on HTTPS endpoints.

Types of HSTS

Dynamic HSTS: Dynamic means that the browser has been instructed to enable HSTS by an HTTP response header (served over TLS) similar to the following:

Strict-Transport-Security: max-age=31536000; includeSubDomains;

This is vulnerable to an attack whereby the very first time the browser requests the domain with http:// (not https://) an adversary intercepts the communication.

Static HSTS: In order to overcome this weakness we have the static mode which allows for hard-coding HSTS records directly into the browser's source. The header is changed to indicate the administrator's intention - note the inclusion of preload at the end:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

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)

HSTS Considerations

When moving to HSTS, bear in mind:

• The policy should be deployed at https://domain.gc.ca, not your HTTP endpoint, nor https://www.domain.gc.ca, added to your .htaccess file.
• 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
• 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.

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 Configuration for WordPress

For Wordpress, add the header info to the functions.php file.

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. CISAGOV-pshtt (Github) - fully explains HSTS measurement by domain-scan
2. HSTS Spec (IETF)
3. Mozilla Configuration Generator
4. HSTS Preload
5. OWASP HSTS Cheat Sheet
6. OWASP Secure Cookie page
7. Browser support for HSTS
8. HSTS web developer documentation maintained by the Mozilla community
9. HSTS Cheat Sheet (Scott Helme)