A patch to control TLS version fallback was developed in response to bug 1076983. We ultimately decided to disable SSLv3 entirely, but the feature is still useful.

Carrying r=keeler from bug 1076983 attachment 8501520 [details] [diff] [review]. Approval Request Comment [Feature/regressing bug #]: 1083058 [User impact if declined]: I think that this patch should follow bug 1076983 out, though perhaps not as far back as ESR. The risk is that someone uses a pref to enable SSLv3 for specific sites (enterprise cases in particular). That opens those users up to POODLE attacks due to our insecure downgrade. This prevents the insecure downgrade to SSLv3. Furthermore, if bug 1076983 reveals breakage in sites that we can't tolerate. We can back that out and get the limited protection that this patch offers. [Describe test coverage new/current, TBPL]: New unit tests (in patch); tbpl (comment 1); manual testing. [Risks and why]: Without bug 1076983, this will break site compatibility with sites that only offer a TLS-intolerant SSLv3 stack. This is a strict subset of the sites affected by disabling SSLv3 entirely (bug 1076983). [String/UUID change made/needed]: None Note: different patches are required for older releases.

Rebased to beta. Approval Request Comment, see comment 2

Is the plan only to land this on 34 or do you want this in 34+? Also, isn't the primary audience for this change enterprises, who, unless we backport, won't get this change on ESR until June 2015 at the earliest?

All of which are good questions. Aren't we porting bug 1076983 to ESR 31.3? I think that that would cover that aspect. Basically, I think that this should follow 1076983. ESR primarily for the reasons you note. That means I should probably ask for approval for all the b2g variants too.

Should this wait to land until bug 1076983 lands? Note that I would still like to see this land on m-c first and only uplift after the change is verified to be good.

Yes, waiting sounds prudent. I'll land this on m-c shortly. Let's give it a few days to settle there before it goes anywhere else.

Saw a couple of problems in the first, limited try run. Nothing direct, so I'm giving this more chances to fail. https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=eef2fcb97048

https://hg.mozilla.org/releases/mozilla-aurora/rev/28cee61603fa https://hg.mozilla.org/releases/mozilla-beta/rev/ae15f14a1db1

[Tracking Requested - why for this release]: per comment 6

Could someone who understands this well, update http://kb.mozillazine.org/Security.tls.version.* ? My understanding is that for most sites the maximum of security.tls.version.{fallback-limit,min} determines the lowest TLS version Firefox is willing to try, but I'm not sure why a separate .min pref is needed -- to control what minimum version is available for "insecure fallback hosts" (security.tls.insecure_fallback_hosts.*, bug 1084025)?