Privacy/Features/HSTS Preload List

Status

Team

Open issues/risks

`

Stage 1: Definition

1. Feature overview

HTTP Strict-Transport-Security (HSTS) allows sites to specify that they should be accessed via a secure connection only. The problem is, a user's first request to a site employing HSTS may not be over HTTPS. A preload list will allow us to ship Firefox with some pre-set HSTS sites that, from the first time they're accessed in the browser, will require a secure connection.

2. Users & use cases

• Sensitive sites that want HTTPS always and never HTTP

3. Dependencies

This depends on HSTS, which landed and shipped with Firefox 4.

4. Requirements

• It must be easy for sites to get on the list
• It must be hard for someone to put a site that doesn't want HSTS onto the list
• We must be able to change the list quickly without shipping a new version of the product

Non-goals

• This does not change the underlying transport or feature (HSTS, HTTPS or SSL)
• This won't have anything to do with certificate pinning.

Stage 2: Design

5. Functional specification

There are two ways to accomplish this:

1. Hard-code the list in each shipping version of Firefox
2. Stand up a service (like blocklist ping) that serves the list upon request.

If we hard-code the list, we must be able to change it with hot fixes (without shipping new versions of the software).

If we stand up a service, it should be polled pretty regularly.

Google maintains a list in their Chrome source (https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json -- look for mode=force-https). We can use this list, since Google has invested in maintaining and sharing it.

Unfortunately, we can't simply take every entry in Chrome's list with mode:"force-https". This is mostly due to chart.apis.google.com being unable to handle https, which conflicts with the apis.google.com (includeSubdomains=true) entry. Additionally, many sites on that list do not even send an HSTS header, or send one that is short-lived (e.g. www.paypal.com sends a header that expires in 4 hours).

Our preload list must contain only sites that we can say are HSTS with a high degree of confidence. So, starting with Chrome's list (because we have to start somewhere), we will only include sites that:

1. Actually send the HSTS header
2. Have a max-age larger than or equal to 18 weeks (10886400)

Additionally, whether or not to include subdomains will be based on the header the site actually sends, not the contents of Chrome's list.

A tool is under development to automatically take Chrome's list and turn it into something our code can use. It will be an xpcshell script in security/manager/tools/getHSTSPreloadlist.js. To use it, simply run './path/to/xpcshell path/to/security/manager/tools/getHSTSPreloadList.js' (depending on your platform and environment, you may have to set the equivalent of LD_LIBRARY_PATH). After some network communication, the tool will say what sites from the list it did or did not include in the list. It will generate a file in the current directory called nsSTSPreloadList.inc. To update the preload list, this file should be placed in security/manager/boot/src/.

6. User experience design

`

Stage 3: Planning

7. Implementation plan

• Create a mechanism to import a list of sites using HSTS into the permissions manager
  • This mechanism must also be able to remove HSTS sites from the permissions manager if necessary (details TBD)
• Create a mechanism to suck down chrome's list and scrub/reformat it
  • Initially this will be done by manually running a script and obtaining a file that we will check in to mozilla-central along with the above import mechanism code
  • Periodically the script will be re-run, and any changes will be checked in to mozilla-central. Presumably this would be at least once per release.
  • Eventually we (with IT) will set up a server that polls, scrubs and checks in updates to the preload file.
  • TBD: Do we land updates to the preload list on branches?
• In the future, create a mechanism by which URLs can be used as subscription endpoints

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

`

Feature details

Team status notes