Closed Bug 1083058 Opened 7 years ago Closed 7 years ago

A pref to control TLS version fallback


(Core :: Security: PSM, defect)

Not set



Tracking Status
firefox33 --- wontfix
firefox34 + verified
firefox35 --- verified
firefox36 --- verified
firefox-esr31 36+ affected


(Reporter: mt, Assigned: mt)




(2 files)

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.
Attachment #8506326 - Flags: review+
Attachment #8506326 - Flags: approval-mozilla-aurora?
Rebased to beta.

Approval Request Comment, see comment 2
Attachment #8506521 - Flags: review+
Attachment #8506521 - Flags: approval-mozilla-beta?
Duplicate of this bug: 689814
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?
Flags: needinfo?(martin.thomson)
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.
Flags: needinfo?(martin.thomson)
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.
Flags: needinfo?(martin.thomson)
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.
Flags: needinfo?(martin.thomson)
Saw a couple of problems in the first, limited try run.  Nothing direct, so I'm giving this more chances to fail.
Closed: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Blocks: 1084025
Attachment #8506326 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #8506521 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
[Tracking Requested - why for this release]: per comment 6
Duplicate of this bug: 634499
Could someone who understands this well, update* ?

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)?
You need to log in before you can comment on or make changes to this bug.