Security/CryptoEngineering/SHA-1: Difference between revisions
(Created page with "Continuing the plan from the https://blog.mozilla.org/security/2016/10/18/phasing-out-sha-1-on-the-public-web/ blog post: One of the c...") |
(Fix formatting) |
||
| Line 5: | Line 5: | ||
This [https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/ bit us last January], and seems to us to necessitate a careful approach. Right now we have no information about how common a state this is, so we're considering that maybe this is an opportunity for a Telemetry Experiment, where we write a simple addon that connects to a Mozilla HTTPS site and evaluates whether the certificate received is A) the one we expect to be there, and if not B) whether the MITM certificate is using SHA-1, and thus will cause user-breakage. | This [https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/ bit us last January], and seems to us to necessitate a careful approach. Right now we have no information about how common a state this is, so we're considering that maybe this is an opportunity for a Telemetry Experiment, where we write a simple addon that connects to a Mozilla HTTPS site and evaluates whether the certificate received is A) the one we expect to be there, and if not B) whether the MITM certificate is using SHA-1, and thus will cause user-breakage. | ||
== Telemetry Experiment == | |||
I believe we can get the information we need without transmitting any information about the certificate we receive, so this should be anonymous, breaking users down into 4 buckets: | I believe we can get the information we need without transmitting any information about the certificate we receive, so this should be anonymous, breaking users down into 4 buckets: | ||
| Line 17: | Line 17: | ||
The second bucket are users for whom we cannot disable SHA-1 entirely yet; that will be important information later in 2017. | The second bucket are users for whom we cannot disable SHA-1 entirely yet; that will be important information later in 2017. | ||
== After The Experiment == | |||
We've announced in our blog post that we'll be disabling SHA-1 for built-in roots over a period of time, starting in Q4 2016 with Beta users, and finishing up sometime in 2017 with Release users. | We've announced in our blog post that we'll be disabling SHA-1 for built-in roots over a period of time, starting in Q4 2016 with Beta users, and finishing up sometime in 2017 with Release users. | ||
| Line 27: | Line 27: | ||
A tentative schedule for roll-out would be: | A tentative schedule for roll-out would be: | ||
2016 | ==== 2016 ==== | ||
* Week 46: 1% of Beta users | * Week 46: 1% of Beta users | ||
* Week 47: 5% of Beta users | * Week 47: 5% of Beta users | ||
| Line 33: | Line 33: | ||
* Week 49: 50% of Beta users | * Week 49: 50% of Beta users | ||
2017 | ==== 2017 ==== | ||
* Week 4: 100% of Beta users + 1% of Release users | * Week 4: 100% of Beta users + 1% of Release users | ||
* Week 5: 5% of Release users | * Week 5: 5% of Release users | ||
Revision as of 22:25, 1 November 2016
Continuing the plan from the https://blog.mozilla.org/security/2016/10/18/phasing-out-sha-1-on-the-public-web/ blog post:
One of the challenges we know about is that some of our users are affected by logical network appliances that man-in-the-middle (MITM) all of Firefox's connections. If their MITM appliance uses SHA-1 from a publicly-trusted root, any action we take on SHA-1 will affect all their browsing. Note though that this would also be a violation of the Baseline Requirements, so we really hope we won't see this situation occur.
This bit us last January, and seems to us to necessitate a careful approach. Right now we have no information about how common a state this is, so we're considering that maybe this is an opportunity for a Telemetry Experiment, where we write a simple addon that connects to a Mozilla HTTPS site and evaluates whether the certificate received is A) the one we expect to be there, and if not B) whether the MITM certificate is using SHA-1, and thus will cause user-breakage.
Telemetry Experiment
I believe we can get the information we need without transmitting any information about the certificate we receive, so this should be anonymous, breaking users down into 4 buckets:
- Users who are behind a MITM proxy using SHA-1 with an imported root
- Users who are behind a MITM proxy using SHA-1 with a built-in root
- Users who are behind a MITM proxy not using SHA-1
- Users who are not behind a MITM proxy
The first bucket should be zero; if it's non-zero, there is great badness in the Web PKI. The second bucket are users for whom we cannot disable SHA-1 entirely yet; that will be important information later in 2017.
After The Experiment
We've announced in our blog post that we'll be disabling SHA-1 for built-in roots over a period of time, starting in Q4 2016 with Beta users, and finishing up sometime in 2017 with Release users.
The Telemetry Experiment will be a restartless addon; that is also how Hotfixes work. We'll plan to update and resubmit that experiment addon several times, targeting a growing percentage of Beta and then Release users to evaluate SHA-1 breakage.
We can see how often breakage occurs from TLS Error Reporting figures.
A tentative schedule for roll-out would be:
2016
- Week 46: 1% of Beta users
- Week 47: 5% of Beta users
- Week 48: 25% of Beta users
- Week 49: 50% of Beta users
2017
- Week 4: 100% of Beta users + 1% of Release users
- Week 5: 5% of Release users