Marking this private, since bug1138554 is under embargo for another day.

This is going to have to land basically everywhere given the deps. Not sure we we'd do a 38.x chemspill, though.

Yep, agreed on the chemspill. I'd wait for the next release opportunity. It's bad, but not that bad.

I have a slight worry about ESR-31: does this update to NSS remove support for features that will break websites, whether that's roots, ciphers, protocols?

Of the changes since 3.16 that apply to Firefox and HTTPS, here are the ones to watch: Bug 753136 makes NSS stricter in its handling of badly formed TLS extensions. In the time that this has been in Firefox (it landed in 3.17) we've only seen improvements in connection rates. Bug 1086145 makes NSS less tolerant of illegal handshake ordering. Bug 1138554 makes NSS refuse to accept small DH shares (this naturally has a compatibility impact, but it's in the order of 0.2%, see the bug). Of these, the only one with compatibility issues is the last one and we need that to happen, it's $50 for server impersonation otherwise. Other than that, I think I'd be safe in saying that the biggest source of connection failures is the changes we've made in PSM, not NSS.

Tag NSS_3_19_1_BETA1 added. RyanVM, this should be OK for everything short of ESR31. I will make the changes necessary tomorrow (we need to revert some root CA changes for that).

I can run some Try pushes off BETA1, but we can't ship anything other than RTM versions to the release channels.

https://hg.mozilla.org/integration/mozilla-inbound/rev/38ff380719e4 Note: This doesn't bump the configure.in version number check yet. That'll need to wait until the final release.

Backed out for test_WebCrypto_DH.html failures. https://treeherder.mozilla.org/logviewer.html#?job_id=10027515&repo=mozilla-inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/e446922ca04d

Use a 1024-bit prime for DH tests.

Also xpcshell, https://treeherder.mozilla.org/logviewer.html#?job_id=10029113&repo=mozilla-inbound

(In reply to Phil Ringnalda (:philor) from comment #10) > Also xpcshell, > https://treeherder.mozilla.org/logviewer.html#?job_id=10029113&repo=mozilla- > inbound

Which required a clobber to get rid of when it persisted past the backout, so it might well require a clobber on landing to not happen - we've seen troubles with the coreconf.dep hack not actually successfully causing an NSS rebuild before.

The failing testcase presented a 1008-bit RSA key for verification with the expectation that PSM would terminate the connection in an overridable manner due to the small key size. Now that the minimum RSA key size according to NSS is the same as PSM's current policy, NSS terminates the handshake before PSM can get to it. The error code is different and it isn't overridable. This patch reflects these changes.

I would consider 768-bit DHE minimum for ESR, given that enterprises are more likely to run Java.

If this goes to ESR, it's going full strength. The only consideration we have at the moment is for ESR 31 where we committed to retaining 1024 root CAs. On a related note, I've asked for expedited review of this: https://addons.mozilla.org/en-US/firefox/addon/disable-dhe/

Comment on attachment 8608941 [details] [diff] [review] PSM xpcshell test update Review of attachment 8608941 [details] [diff] [review]: ----------------------------------------------------------------- LGTM.

Comment on attachment 8608467 [details] [diff] [review] 0001-Bug-1166031-Use-1024-bit-prime-for-WebCrypto-s-DH-te.patch Review of attachment 8608467 [details] [diff] [review]: ----------------------------------------------------------------- This matches up. Do you have a try run to show us all that it fixed the problem?

(In reply to Martin Thomson [:mt] from comment #17) > This matches up. Do you have a try run to show us all that it fixed the > problem? I'm quite confident they don't fail, the only thing they could do is time out on slow Android debug runs. You didn't ask David for a try push but I guess it doesn't hurt to include his patch too: https://treeherder.mozilla.org/#/jobs?repo=try&revision=cfceb71f03a1

Thanks Tim (I didn't r+ David's patch).

This needs checkin for m-c; let's wait until Monday for Aurora, and Thursday for Beta (as agreed with :lizzard). RyanVM, do you think that you can handle the landing?

https://hg.mozilla.org/integration/mozilla-inbound/rev/5b0d7c8c9cda https://hg.mozilla.org/integration/mozilla-inbound/rev/c2c83077fe1c https://hg.mozilla.org/integration/mozilla-inbound/rev/5039f49a256b Friendly reminder that we'll need an RTM tagging before anything beyond Aurora can be updated.

Reminder acknowledged. RTM will be tagged next Thursday all going well. I'm treating the 31 changes with less urgency, since I'm told that we won't need that for a few more weeks. I need to consult with :kaie about what is needed.

https://hg.mozilla.org/mozilla-central/rev/5b0d7c8c9cda https://hg.mozilla.org/mozilla-central/rev/c2c83077fe1c https://hg.mozilla.org/mozilla-central/rev/5039f49a256b

Approval Request Comment [Feature/regressing bug #]: N/A [User impact if declined]: Security issues noted in the blocking bugs. [Describe test coverage new/current, TreeHerder]: In-tree NSS test coverage, nightly coverage for a couple days. [Risks and why]: Martin can correct me, but the risk seems fairly low. Bug 1138554 references some intranet sites potentially having issues. [String/UUID change made/needed]: N/A

https://hg.mozilla.org/releases/mozilla-aurora/rev/3fc58c44e86b https://hg.mozilla.org/releases/mozilla-aurora/rev/9da10de1195c https://hg.mozilla.org/releases/mozilla-aurora/rev/3df9581c43e5

Comment on attachment 8609924 [details] Update NSS to version 3.19.1 NSS_3_19_1_RTM has been tagged. Let's get this on the other release branches. Note that a modified version of 3.19.1 is being created for ESR31 uplift that backs out 1024bit CA cert changes that affect compat.

Comment on attachment 8609924 [details] Update NSS to version 3.19.1 Approved for uplift to beta, esr31 and esr38 based on discussion with Ryan and Martin.

https://hg.mozilla.org/releases/mozilla-beta/rev/a74ce2833a96 https://hg.mozilla.org/releases/mozilla-beta/rev/b239d4243b6b https://hg.mozilla.org/releases/mozilla-beta/rev/dc9c305024f4

I think enterprises should be allowed some time to upgrade the old Java JSSE stacks.

Please use this tag for Firefox ESR 31.x : NSS_3_19_1_WITH_CKBI_1_98_RTM

(In reply to Kai Engert (:kaie) from comment #33) > Please use this tag for Firefox ESR 31.x : > NSS_3_19_1_WITH_CKBI_1_98_RTM How should I handle the version number in configure.in?

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #34) > (In reply to Kai Engert (:kaie) from comment #33) > > Please use this tag for Firefox ESR 31.x : > > NSS_3_19_1_WITH_CKBI_1_98_RTM > > How should I handle the version number in configure.in? Using 3.19.1 is fine. Both tags identify themselves as version 3.19.1

(In reply to Kai Engert (:kaie) from comment #35) > Using 3.19.1 is fine. > Both tags identify themselves as version 3.19.1 Those distributors who are willing to pick up the root CA changes can use the regular 3.19.1 release. Mozilla will use the special release. All distributors that want the old root CA certificates can distribute the special 3.19.1 release will old root CA set.

(In reply to Yuhong Bao from comment #32) > I think enterprises should be allowed some time to upgrade the old Java JSSE > stacks. How old? JSSE 6 supports 1024-bit DH. Enterprises have already had plenty of time there. http://www.oracle.com/technetwork/java/eol-135779.html NSS_3_19_1_WITH_CKBI_1_98_RTM is a one-off for Firefox ESR 31. Affected enterprises can remain on Firefox 31, but know that support for that ends relatively soon.

JSSE client != JSSE server.

(In reply to Yuhong Bao from comment #38) IE also banned the short DHE key without any backward compatible options. I don't understand why do you insist ancient JSSE version while trying to drop WinXP SP2 support. Please be consistent at least.

Enterprises don't typically run XP SP2, and Java 7 is not nearly as "ancient".

Java 7 supports 1024-bit DHE keys, no? Please cite a reference if not.

My ESR31 Try push is seeing test_CSP_evalscript_getCRMFRequest.html failures: https://treeherder.mozilla.org/logviewer.html#?job_id=7999693&repo=try dkeeler says I'm OK to just disable the test as this is expected PSM behavior now (and the test itself was removed back in the Gecko 34 days). https://hg.mozilla.org/releases/mozilla-esr31/rev/eba99d1ad886 https://hg.mozilla.org/releases/mozilla-esr31/rev/9cddd14f9c22

(In reply to Masatoshi Kimura [:emk] from comment #41) > Java 7 supports 1024-bit DHE keys, no? Please cite a reference if not. On the client side. On the server side it still used 768-bit DHE. I filed an IcedTea bug on this: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2250

While I'm a little sad about making older Java unreachable, I think that filing bug reports with Java implementations is the right answer. DHE at 768-bits is far too weak.

And my point is that I doubt one month is enough time to upgrade.

https://hg.mozilla.org/releases/mozilla-esr38/rev/b68c2aa2ba17 https://hg.mozilla.org/releases/mozilla-esr38/rev/e4122cc66111 https://hg.mozilla.org/releases/mozilla-esr38/rev/104927365946

https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a84adb412f87 https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/239793ea749a

Unfortunately, the Try pushes for b2g34/b2g37 are having some xpcshell issues. Both are failing in test_cert_overrides.js with the following error: 17:53:39 INFO - found pre-defined host 'inadequate-key-size-ee.example.com' 17:53:39 INFO - found pre-defined host 'inadequate-key-size-ee.example.com' 17:53:39 INFO - TEST-INFO | /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/head_psm.js | "handling inadequate-key-size-ee.example.com" 17:53:39 INFO - TEST-PASS | /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/head_psm.js | [add_connection_test/</< : 315] 2153394044 == 2153394044 17:53:39 INFO - PR_Recv failed: SSL_ERROR_INSUFFICIENT_SECURITY_ALERT 17:53:39 WARNING - TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_cert_overrides.js | [object XPCWrappedNative_NoHelper] == null - See following stack: 17:53:39 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_cert_overrides.js:add_non_overridable_test/<:45 17:53:39 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/head_psm.js:add_connection_test/</<:317 17:53:39 INFO - resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:Handler.prototype.process:865 17:53:39 INFO - resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:this.PromiseWalker.walkerLoop:744 17:53:39 INFO - /builds/slave/test/build/tests/xpcshell/head.js:_do_main:191 17:53:39 INFO - /builds/slave/test/build/tests/xpcshell/head.js:_execute_test:405 17:53:39 INFO - -e:null:1 17:53:39 INFO - null:null:0 Additionally, b2g34 is also failing in test_keysize.js with: 17:55:03 INFO - TEST-INFO | /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js | "cert cn=dsa-eeOK-intOK-caOK" 17:55:03 INFO - TEST-INFO | /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js | "cert issuer cn=dsa-intOK-caOK" 17:55:03 WARNING - TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js | -16382 == 0 - See following stack: 17:55:03 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js:check_cert_err_generic:31 17:55:03 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js:check_cert_err:35 17:55:03 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js:check_ok:39 17:55:03 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js:check_for_key_type:60 17:55:03 INFO - /builds/slave/test/build/tests/xpcshell/tests/security/manager/ssl/tests/unit/test_keysize.js:run_test:77 17:55:03 INFO - /builds/slave/test/build/tests/xpcshell/head.js:_execute_test:403 17:55:03 INFO - -e:null:1 17:55:03 INFO - null:null:0 Full log link: https://treeherder.mozilla.org/logviewer.html#?job_id=8004661&repo=try

For the test_keysize.js failures, it looks like openssl was generating DSA keys that NSS considers to be 1023 bits, not 1024. I upped the size and regenerated the affected keys. Note that I didn't investigate the further question of if openssl is doing the right thing or if NSS is doing the right thing. The reason this isn't failing in more recent branches is that we removed support for these certificates from firefox entirely.

Thus far PSM has relied on a convention where if certificate verification results in a non-overridable error, no ssl status object will be set on the transport security info object representing the connection. It turns out, if both NSS and PSM encounter an error, this assumption can be violated. Some of our tests rely on this assumption, which is why test_cert_overrides.js broke. I don't think there's an easy fix. This just modifies the relevant test to verify what we can verify, which is that the appropriate error is recorded. Note that while this is a bad state to be in, it isn't a security disaster because if NSS encounters an error, it will not let the connection continue, no matter what PSM says.

(In reply to David Keeler [:keeler] (use needinfo?) from comment #50) > For the test_keysize.js failures, it looks like openssl was generating DSA > keys that NSS considers to be 1023 bits, not 1024. That's odd. We only reject DSA values at 1022 or less (DSA_MIN_P_BITS is 1023).

I should have been more specific: before 38, mozilla::pkix would use NSS to determine a key's strength in bits. As of 3.19.1, SECKEY_PublicKeyStrengthInBits appears to return 1023 for the keys in the test. mozilla::pkix's limit is 1024, so they were rejected.

Comment on attachment 8613120 [details] [diff] [review] test_keysize update Review of attachment 8613120 [details] [diff] [review]: ----------------------------------------------------------------- DSA, please stop haunting us. Anyways, LGTM. Try push would be nice, but I assume RyanVM will take care of that.

Comment on attachment 8613126 [details] [diff] [review] test_cert_overrides update Review of attachment 8613126 [details] [diff] [review]: ----------------------------------------------------------------- Interesting, thanks for the explanation. Anyways, LGTM.

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/1ad8a7e8dcfb https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/76bd11cf59e9 https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/fbf1127b1313

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/685bd8d49ce3 https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/f22235875dc0 https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/94d943fadb06 https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/eb6e7d9d336a

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/685bd8d49ce3 https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/f22235875dc0 https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/94d943fadb06 https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/eb6e7d9d336a https://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/rev/a84adb412f87 https://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/rev/239793ea749a

Also see: https://bugs.openjdk.java.net/browse/JDK-6956398 Notice the backports to 7u85 and 6u101. We should at least make sure that these are released before trying to disable 768-bit DHE.