Securedrop: Add `preload` directive to securedrop.org

[Hainish]

securedrop.org is included in the HSTS preload list, and preloaded for both Chromium and Firefox:

https://hg.mozilla.org/releases/mozilla-aurora/raw-file/tip/security/manager/ssl/nsSTSPreloadList.inc
https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json

However, it does not include the preload directive as specified as a requirement for inclusion in the HSTS preload list:

The preload directive must be specified.

user@https-everywhere ~/workspace/https-everywhere (hsts-prune) $ curl -I https://securedrop.org
HTTP/1.1 200 OK
Date: Tue, 10 Jan 2017 04:20:51 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Set-Cookie: __cfduid=def4f417abc22de400dc6ad8b0617cf9e1484022051; expires=Wed, 10-Jan-18 04:20:51 GMT; path=/; domain=.securedrop.org; HttpOnly
X-Content-Type-Options: nosniff
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: no-cache, must-revalidate
X-Content-Type-Options: nosniff
Content-Language: en
X-Frame-Options: SAMEORIGIN
X-Generator: Drupal 7 (http://drupal.org)
Link: <https://securedrop.org/>; rel="canonical",<https://securedrop.org/>; rel="shortlink"
Strict-Transport-Security: max-age=15768000
Access-Control-Allow-Origin: *
Server: cloudflare-nginx
CF-RAY: 31ed56bf79001e71-SJC

This has not been grounds for removal from the list yet, but it will be in the future:

Chrome has not yet removed any domains from the preload list for failing to keep up the requirements after submission, but there are plans to do so in the future.

https://hstspreload.org/

You'll want to fix this to ensure inclusion in the preload list.

[garrettr]

However, it does not include the preload directive as specified as a requirement for inclusion in the HSTS preload list

Well, obviously it did at one point in the past in order for it to be successfully added to the preload list. My understanding of the preload directive is that it primarily meant to be an anti-abuse mechanism for the automated (or at least, somewhat automated) current protocol for adding sites to the preload list. I really don't see what the point would be of continuing to serve it after a site has been added to the preload list.

This has not been grounds for removal from the list yet, but it will be in the future

Thanks for bringing this to my attention! I had not noticed this language on https://hstspreload.org/.

Again, I think it would be bizarre and nonsensical if Chrome started removing sites from the preload list because they stopped sending the preload directive. My hunch is that this warning is meant as a defense against other types of preloading requirements relapse, which are much more common and do have an impact on the security for end users: for example, reducing maxAge or removing includeSubDomains.

I will try to confirm this hunch by reaching out to Lucas Garron, who is the point of contact listed for https://hstspreload.org/.

[garrettr]

I will try to confirm this hunch by reaching out to Lucas Garron, who is the point of contact listed for https://hstspreload.org/.

Email sent.

[garrettr]

Automated reply:

Thanks for your email regarding the HSTS Preload List!

Due to the volume of requests, I handle emails to this address in batches; please allow up to a week for a reply.

[lgarron]

Chrome has not yet removed any domains from the preload list for failing to keep up the requirements after submission, but there are plans to do so in the future.

Also note the next sentence:

In particular, note that the requirements above apply to all domains submitted through hstspreload.org (or hstspreload.appspot.com) on or after February 29, 2016 (i.e. preloaded after Chrome 50).

When the flood of submissions picked up this time last year, I put the policy in place starting on Feb. 29 (when Chrome 50 branched) so that could can avoid accidental or stale entries for future submissions.

Older entries, including securedrop.org, are in a long-term policy limbo. They were submitted under less formal conditions, so we need to be very careful about pruning them – but we don't want to keep stale entries forever just because they were submitted early. One of my tasks for 2017 is to work with other browsers to develop a good plan for stale entries, but I can't yet make any promises about what that will look like.

In the case of securedrop.org, I strongly recommend adding includeSubDomains and preload back to the header. Since this matches the preloaded value, it should not cause any issues in modern browsers. And this will keep the site preloaded no matter what policy changes we make for pruning old entries.

[garrettr]

Thanks for the info, @lgarron! We'll add those directives back to the HSTS header on securedrop.org by the end of the week (cc @conorsch @msheiny). And thanks to @Hainish for the report!

[msheiny]

Thanks @lgarron and @Hainish ! Site headers have been updated

For your bravery in security reporting, please accept this digital trophy :1st_place_medal: