I suggest to upgrade the Firefox 31 Enterprise Support branch (ESR) to a newer NSS version, which implements support for the TLS_FALLBACK_SCSV. While Firefox 31.3 will probably disable SSL 3 by default (currently being discussed), there might be users that are required to re-enable SSL 3, because they have to work with legacy devices in their environment. Using a version of NSS that supports TLS_FALLBACK_SCSV and the patch from bug 1036737 might benefit those users.
At this time, Firefox 31 ESR uses NSS 220.127.116.11 TLS_FALLBACK_SCSV was added in NSS 3.17.2, in bug 1036735 I suggest to backport the patch to the NSS 3.16.2.x branch, and use a new release from that branch for Firefox 31 ESR.
:kaie can this be marked as a duplicate of bug 1036735? I don't want to have the discussion in two places.
Martin, this is a Firefox/PSM bug. We usually have a separate tracking bug (to carry approvals) for Firefox releases. Bug 1036735 is a NSS bug. IMHO, all discussions related to NSS and backporting to NSS branches should happen in bug 1036735. This bug is intended to discuss whether or not to upgrade Firefox 31.
My mistake. I always confuse the bugs on this. bug 1036737 is what I intended to ask about. That's where I landed the Firefox/PSM changes.
Ok, maybe you're right, and using bug 1036737 is fine.
I'm reopening this as its own bug, because NSS 18.104.22.168 includes an additional bugfix. This bug is for tracking a potential upgrade of NSS on the Firefox 31 ESR branch. Landing the patch from bug 1036737, which enables the feature, is a separate decision. [Tracking Requested - why for this release]: Firefox ESR could benefit from the TLS_FALLBACK_SCSV feature after POODLE and from a 100% cpu fix which are available in NSS 22.214.171.124 This is a minimal NSS update, with these fixes backported.
Created attachment 8511380 [details] [diff] [review] Illustrative patch (for landing use: python client.py update_nss NSS_3_16_2_3_RTM) This patch illustrates the amount of changes between the currently used NSS 126.96.36.199 and the suggested upgrade to 188.8.131.52 Using this patch for requesting approval.
esr-31 try build, using the patch from this bug, plus the patch from bug 1036737: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=f69e43df260f
Comment on attachment 8511380 [details] [diff] [review] Illustrative patch (for landing use: python client.py update_nss NSS_3_16_2_3_RTM) Review of attachment 8511380 [details] [diff] [review]: ----------------------------------------------------------------- r=wtc.
Paul, should we consider this for B2G v1.4/v2.0 as well?
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #10) > Paul, should we consider this for B2G v1.4/v2.0 as well? Yes that sounds like a good idea to me (and 2.0m).
Comment on attachment 8511380 [details] [diff] [review] Illustrative patch (for landing use: python client.py update_nss NSS_3_16_2_3_RTM) See comment 6 and comment 11.
Bump the minimum version in configure.in as well: https://hg.mozilla.org/releases/mozilla-esr31/rev/e70de1bbcf5f
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/6fa3af960fff B2G v2.0 (b2g32) is actually on NSS 3.16.5 at the moment. Kai, what should we do for that release?
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #15) > https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/6fa3af960fff > > B2G v2.0 (b2g32) is actually on NSS 3.16.5 at the moment. Kai, what should > we do for that release? It would be best if you could go to 3.17.2 The 3.16.2.x branch is primarily intended for those branches that still require the old set of root CA certs (which we don't want to change on FF 31 ESR). If you use 3.16.5, you already have the new root CA changes.
Thanks, I'll move it over to bug 1049435 then.
I accidentally just pushed an empty to commit to Aurora under this bug number. It's completely safe to ignore. Sorry for any confusion it causes. https://hg.mozilla.org/releases/mozilla-aurora/rev/ee017c79f5a8