Privacy/Features/HSTS Preload List: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 13: Line 13:
}}
}}
{{FeaturePageBody
{{FeaturePageBody
|Feature overview=HTTP Strict-Transport-Security (HSTS) allows sites to specify that they would like to be accessed via HTTPS 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 HTTPS.
|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.
|Feature users and use cases=* Sensitive sites that want HTTPS always and never HTTP
|Feature users and use cases=* Sensitive sites that want HTTPS always and never HTTP
|Feature dependencies=This depends on HSTS, which landed and shipped with Firefox 4.
|Feature dependencies=This depends on HSTS, which landed and shipped with Firefox 4.
Line 29: Line 29:
If we stand up a service, it should be polled pretty regularly.
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/base/transport_security_state_static.json -- look for mode=force-https).  We can use this list, since Google has invested in maintaining and sharing it.
Google maintains a list in their Chrome source (https://src.chromium.org/viewvc/chrome/trunk/src/net/base/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:
# Actually send the HSTS header
# Have a max-age larger than or equal to 18 weeks (10886400)
|Feature implementation plan=* Create a mechanism to import a list of sites using HSTS into the permissions manager
|Feature 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)
** This mechanism must also be able to remove HSTS sites from the permissions manager if necessary (details TBD)
Line 37: Line 43:
** Eventually we (with IT) will set up a server that polls, scrubs and checks in updates to the preload file.
** 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?
** TBD: Do we land updates to the preload list on branches?
** Currently ssh://hg.mozilla.org/users/dkeeler_mozilla.com/sts-preload has an early version of this script and its output
* In the future, create a mechanism by which URLs can be used as subscription endpoints
* In the future, create a mechanism by which URLs can be used as subscription endpoints
}}
}}

Revision as of 18:47, 31 August 2012

Please use "Edit with form" above to edit this page.

Status

HSTS Preload List
Stage Development
Status In progress
Release target Firefox 17
Health OK
Status note `

{{#set:Feature name=HSTS Preload List

|Feature stage=Development |Feature status=In progress |Feature version=Firefox 17 |Feature health=OK |Feature status note=` }}

Team

Product manager Sid Stamm
Directly Responsible Individual David Keeler
Lead engineer David Keeler
Security lead `
Privacy lead Sid Stamm
Localization lead `
Accessibility lead `
QA lead `
UX lead `
Product marketing lead `
Operations lead `
Additional members `

{{#set:Feature product manager=Sid Stamm

|Feature feature manager=David Keeler |Feature lead engineer=David Keeler |Feature security lead=` |Feature privacy lead=Sid Stamm |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

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/base/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)

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

` {{#set:Feature open issues and risks=` |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. |Feature users and use cases=* Sensitive sites that want HTTPS always and never HTTP |Feature dependencies=This depends on HSTS, which landed and shipped with Firefox 4. |Feature 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

|Feature 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.

|Feature functional spec=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/base/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)

|Feature ux design=` |Feature 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

|Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority P1
Rank 999
Theme / Goal HTTPS By Default
Roadmap Security
Secondary roadmap Platform
Feature list `
Project `
Engineering team `

{{#set:Feature priority=P1

|Feature rank=999 |Feature theme=HTTPS By Default |Feature roadmap=Security |Feature secondary roadmap=Platform |Feature list=` |Feature project=` |Feature engineering team=` }}

Team status notes

  status notes
Products ` `
Engineering ` `
Security ` `
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}


Retrieved from "https://wiki.mozilla.org/index.php?title=Privacy/Features/HSTS_Preload_List&oldid=466420"