Security/CryptoEngineering/SHA-1

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 January 2016, 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 (Dec 2016)

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:

1. Users who are behind a MITM proxy using SHA-1 with a built-in root
2. Users who are behind a MITM proxy using SHA-1 with an imported root
3. Users who are behind a MITM proxy not using SHA-1
4. 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.

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'll 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 a restartless system addon. We'll plan to update and re-ship that addon 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.

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 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 addon 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 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 simply 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.)