View source for Security/CryptoEngineering/SHA-1

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]:

== 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 [https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/ 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=1323851 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: [https://gist.github.com/jcjones/098c9ee81213e6816cf372194f45e918]
   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 [https://bugzilla.mozilla.org/show_bug.cgi?id=1321114 Bug 1321114] (and the initial code is in [https://bugzilla.mozilla.org/show_bug.cgi?id=1328718 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.

=== Tentative Sampled Rollout Timeline ===

(Week 4: Release of 51)
* Week 4: 10% of Beta 52 users
* Week 5: 50% of Beta 52 users
* Week 6: 100% of Beta 52 users
* Week 7: 100% of Beta 52 users + 5% of Release 51 users
* Week 8: 100% of Beta 52 users + 10% of Release 51 users
* Week 8: 100% of Beta 52 users + 25% of Release 51 users
* Week 9: 100% of Beta 52 users + 50% of Release 51 users
(Week 10: Release of 52)
* Week 10: On by preference in Beta + 100% of Release 51 users

(Week 16: Release of 53)
* Week 16: On by preference in Release

=== Identified Risks ===

This change isn't like that of [https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/ 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 ====

[https://telemetry.mozilla.org/new-pipeline/evo.html#!aggregates=bucket-1!bucket-2!bucket-3!bucket-4!bucket-5&cumulative=0&end_date=null&keys=&max_channel_version=release%252F50&measure=CERT_CHAIN_SHA1_POLICY_STATUS&min_channel_version=release%252F46&product=Firefox&sanitize=1&sort_keys=submissions&start_date=null&trim=1&use_submission_date=0 Telemetry indicates that 0.09%] of Release 50 connections still occur to sites with certificates signed with SHA-1. [https://censys.io/ipv4?q=443.https.tls.certificate.parsed.signature_algorithm.name%3A%22SHA1WithRSA%22+AND+443.https.tls.certificate.parsed.validity.end%3A++%5B2016-01-10+TO+*%5D+AND+443.https.tls.validation.browser_trusted%3A+true 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.)