Security/CryptoEngineering/SHA-1
NOTE: This work is completed with Firefox 52. Preserved for posterity.
Continuing the plan from the Phasing Out SHA-1 On The Public Web blog post:
Contents
MITM Appliances Using SHA-1
One of the challenges involved with disabling SHA-1 is that some of our users are affected by 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 of their browsing. Note that such a setup would be a considerable violation of the Baseline Requirements.
Telemetry Experiment (Dec 2016)
This bit us in January 2016, and seems to necessitate a careful approach. Previously we had no information about how common this might be, so we conducted a Telemetry Experiment where we wrote a simple add-on 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 from a publicly-trusted root, and thus would cause user-breakage.
Results
Posted in Bug 1323851:
On this dataset, we've confirmed that we can disable SHA-1 for non-built-in-roots without breaking updates. One analysis dataset is here: [1] The final dataset was: {'isAccum': True, 'rooterrors': Counter({'0f993c8aef97baaf5687140ed59ad1821bb4afacf0aa9a58b5d57a338a3afbcb -12276': 1, '4348a0e9444c78cb265e058d5e8944b4d84f9662bd26db257f8934a443c70161 0': 2822178, '687fa451382278fff0c8b11f8d43d576671c6eb2bceab413fb83d965d06d2ff2 -12276': 22, '73c176434f1bc6d5adf45b0e76e727287c8de57616c1e6e6141a2b2cbc7d8e4c -12276': 1, 'c3846bf24b9e93ca64274c0ec67c1ecc5e024ffcacd2d74019350e81fe546ae4 -12276': 1, 'ff856a2d251dcd88d36656f450126798cfabaade40799c722de4d2b5db36a73a -12276': 1}), 'total_errors': Counter({-16381: 1, -16379: 11, -16378: 1, -12276: 53, -12173: 1, -8191: 1, -8179: 299, -8162: 14, -8061: 351, -8016: 28}), 'total_roots': Counter({u'0f993c8aef97baaf5687140ed59ad1821bb4afacf0aa9a58b5d57a338a3afbcb': 1, u'4348a0e9444c78cb265e058d5e8944b4d84f9662bd26db257f8934a443c70161': 2822178, u'687fa451382278fff0c8b11f8d43d576671c6eb2bceab413fb83d965d06d2ff2': 22, u'73c176434f1bc6d5adf45b0e76e727287c8de57616c1e6e6141a2b2cbc7d8e4c': 1, u'c3846bf24b9e93ca64274c0ec67c1ecc5e024ffcacd2d74019350e81fe546ae4': 1, u'ff856a2d251dcd88d36656f450126798cfabaade40799c722de4d2b5db36a73a': 1})} This means the only instances of having an errorCode=0 (successful connection) are for the legitimate root. The MITM-esque situations are all combined with SSL_ERROR_BAD_CERT_DOMAIN (code -12276). Other errors are small and normal-seeming, too: -16381: (1) MOZILLA_PKIX_ERROR_V1_CERT_USED_AS_CA -16379: (11) MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE -16378: (1) MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE -12276: (53) SSL_ERROR_BAD_CERT_DOMAIN -12173: (1) SSL_ERROR_WEAK_SERVER_EPHEMERAL_DH_KEY -8191: (1) SEC_ERROR_LIBRARY_FAILURE -8179: (299) SEC_ERROR_UNKNOWN_ISSUER -8162: (14) SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE -8061: (351) SEC_ERROR_OCSP_FUTURE_RESPONSE -8016: (28) SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED
Sampled Rollout of the Deprecation Policy (Q1 2017)
We've announced in our blog post that we will be disabling SHA-1 for built-in roots over a period of time, starting with Beta users, and finishing up sometime in early 2017 with Release users.
The Sampled Rollout will be implemented via a restartless system add-on. We'll plan to update and re-ship that add-on several times, targeting a growing percentage of Beta and then Release users to evaluate SHA-1 breakage. This work is being done in Bug 1321114 (and the initial code is in Bug 1328718).
We can see how often site breakage occurs from TLS Error Reporting statistics, and monitor progress on the rollout via the same telemetry result data format as the prior experiment.
Final Sampled Rollout Timeline
(Updated 14 Feb 2017)
(Week 4: Release of 51)
- Week 5: 10% of Beta 52 users [Bug 1328718]
- Week 6: 50% of Beta 52 users [Bug 1336616]
- Week 7: 100% of Beta 52 users + 25% of Release 51 users [Bug 1338228]
- Week 8: Uplift preference to Beta 52 [Bug 1330043] + 100% of Release 51 users [Bug 1339662]
- Week 9: No change from week 8
(Week 10: Release of 52)
- Week 10: On by preference in Release 52
Identified Risks
This change isn't like that of January 2016 - it only enforces the SHA-1 ban on publicly trusted (e.g., 'built-in') roots. It doesn't affect imported roots from AV software or enterprise deployments.
There are two risk categories we’ve identified:
- Publicly-trusted certificate authorities [mis-]issuing Man-In-The-Middle certificates using a SHA-1 signature algorithm.
- Older than 2014 but still-valid publicly-trusted certificates using a SHA-1 signature algorithm that haven’t been replaced.
Publicly-Trusted Man-In-The Middle of Mozilla Properties
If a publicly-trusted CA issues or has issued a SHA-1 man-in-the-middle certificate for Mozilla's update servers, we could be broken without recourse. Note that our December experiment didn't find any rogue CAs. Also, we are not using SHA-1 certificates for our update or telemetry servers, so this would require a CA to cooperate in the attack.
To mitigate this risk, before changing the preference, the add-on performs the same probe test as our earlier experiment: ensuring that connections to telemetry.mozilla.org succeed without a publicly-trusted man-in-the-middle using SHA1 interfering. (Of course, if we identified such a man-in-the-middle, we would almost certainly revoke the issuing CA using OneCRL, as it would be a critical danger to the web!)
Pre-SHA-1 Ban Certificates Still In Use
Telemetry indicates that 0.09% of Release 50 connections still occur to sites with certificates signed with SHA-1. Censys.io queries based on scans of IPv4 show that ~300,000 hosts are still using SHA-1 certificates signed by a publicly-trusted root. That said, 11% of those are revoked certificates for "securelogin.arubanetworks.com", and upon manual inspection, many are for back-end payment processor systems that are not a part of the web.
Mitigating this risk has mostly been policy and advocacy work on the part of the CA/Browser Forum since the ban effort began in 2014. The other side of mitigating this risk is this sampled rollout.
(Note that Chrome is in the middle of a similar sampled rollout in December '16-January '17, with their total ban coming into effect before our sampled rollout begins, so that will also help encourage site owners to upgrade.)
Compatibility Help for Site Operators
The fx-site-compat team has written up the change here: https://www.fxsitecompat.com/en-CA/docs/2016/sha-1-certificates-issued-by-public-ca-will-no-longer-be-accepted/
Completion
This roll-out completed on schedule, and the total deprecation happened with the release of Firefox 52.