Security/CryptoEngineering/SHA-1

From MozillaWiki
Jump to: navigation, search

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:

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

  1. Publicly-trusted certificate authorities [mis-]issuing Man-In-The-Middle certificates using a SHA-1 signature algorithm.
  2. 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.

Retrieved from "https://wiki.mozilla.org/index.php?title=Security/CryptoEngineering/SHA-1&oldid=1165541"