Security/CryptoEngineering/SHA-1: Difference between revisions
(Fix formatting) |
(Fix link) |
||
| Line 1: | Line 1: | ||
Continuing the plan from the [ | Continuing the plan from the [https://blog.mozilla.org/security/2016/10/18/phasing-out-sha-1-on-the-public-web/ 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. | 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. | ||
Revision as of 22:25, 1 November 2016
Continuing the plan from the 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