Security/CryptoEngineering/SHA-1: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(→‎2016: updates)
(Note completion)
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
'''NOTE: This work is completed with Firefox 52. Preserved for posterity.'''
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]:
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.
== 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.
 
=== Final Sampled Rollout Timeline ===
(Updated 14 Feb 2017)
 
(Week 4: Release of 51)
* Week 5: 10% of Beta 52 users [[https://bugzilla.mozilla.org/show_bug.cgi?id=1328718 Bug 1328718]]
* Week 6: 50% of Beta 52 users [[https://bugzilla.mozilla.org/show_bug.cgi?id=1336616 Bug 1336616]]
* Week 7: 100% of Beta 52 users + 25% of Release 51 users [[https://bugzilla.mozilla.org/show_bug.cgi?id=1338228 Bug 1338228]]
* Week 8: Uplift preference to Beta 52 [[https://bugzilla.mozilla.org/show_bug.cgi?id=1330043 Bug 1330043]] + 100% of Release 51 users [[https://bugzilla.mozilla.org/show_bug.cgi?id=1339662 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 [https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/ 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.
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.


== Telemetry Experiment ==
There are two risk categories we’ve identified:


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


# Users who are behind a MITM proxy using SHA-1 with a built-in root
==== Publicly-Trusted Man-In-The Middle of Mozilla Properties ====
# Users who are behind a MITM proxy using SHA-1 with an imported 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.
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.
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 ==
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!)


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.
==== Pre-SHA-1 Ban Certificates Still In Use ====


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.
[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.


We can see how often breakage occurs from TLS Error Reporting figures.
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.


A tentative schedule for roll-out would be:
(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.)


==== 2016 ====
== Compatibility Help for Site Operators ==
* Week 48: 1% of Beta users
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/
* Week 49: 5% of Beta users


==== 2017 ====
= Completion =
* Week 4: 100% of Beta users + 1% of Release users
This roll-out completed on schedule, and the total deprecation happened with the release of Firefox 52.
* Week 5: 5% of Release users

Latest revision as of 01:01, 14 March 2017

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.allizom.org/index.php?title=Security/CryptoEngineering/SHA-1&oldid=1165541"