Security/CryptoEngineering/SHA-1: Difference between revisions

Security/CryptoEngineering/SHA-1 (view source)

Revision as of 18:43, 13 January 2017

6,069 bytes added , 13 January 2017

Address risks, update schedule

Jcjones

122

edits

@@ Line 3: / Line 3: @@
 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 [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 [https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/ 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 ==
+== 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:
@@ Line 17: / Line 17: @@
 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 ==
+=== Results ===
+Posted in [https://bugzilla.mozilla.org/show_bug.cgi?id=1323851 Bug 1323851]:
-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.
+   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
-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. This work is being done in [https://bugzilla.mozilla.org/show_bug.cgi?id=1321114 Bug 1321114].
-We can see how often breakage occurs from TLS Error Reporting figures.
+== Sampled Rollout of the Deprecation Policy (Q1 2017) ==
-A tentative schedule for roll-out would be:
+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.
-==== 2017 ====
+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 [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]).
-* Week 4: 10% of Beta users
+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.
-* Week 5: 50% of Beta users
-* Week 6: 100% of Beta users + 1% of Release users
-* Week 7: 5% of Release users
+=== 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 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 ====
+[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  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.)