Closed Bug 1626495 Opened 2 months ago Closed 2 months ago

Re-enable TLS 1.0 in Firefox 76 and 77 (Release)


(Core :: Security: PSM, task, P1)




Tracking Status
firefox76 blocking fixed


(Reporter: mt, Assigned: mt)


(Blocks 1 open bug)


(Keywords: site-compat)


(1 file)

Based on recent discussions, it seems like Google and Microsoft are delaying their deployment of the TLS 1.0 changes until June. We should too.

This involves backing out changes from Bug 1606734, which we then back out again later.

Pushed by
Re-enable TLS 1.0 for release, r=keeler
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76

This seems dangerous in the sense that any fallout from this change won't be seen until RC week at the earliest. Can we please change this condition so that Beta builds are also affected so there's time to address any problems during the Beta cycle rather than in an RC respin or dot release?

Flags: needinfo?(mt)

With regards to user impact, this shouldn't be a problem -- users will see fewer disruptions with TLS 1.0 and TLS 1.1 enabled. Also, we re-enabled for 75 due to the COVID-19 situation. We want to use the Beta channel for testing the disablement of TLS 1.0 and 1.1 (i.e., not have those versions enabled but default in Beta) so that we can move forward with deprecation the Release channel later. What fallout specifically are you worried about? And perhaps MT can say more.

In general, we try to keep our Beta releases as representative as possible to what will eventually ship, so having a behavior change gated on being a release build adds risk should there be unexpected web compat fallout that we don't see until the release is nearly about to ship. I understand that in general this change should make us more compatible than before, but we all know that the web can be a crazy place sometimes :)

Note that we also have an EARLY_BETA_OR_EARLIER flag which may be appropriate here, where 1.2 could be the minimum for the first half of the Beta cycle before being automatically switched to 1.0 in the lead-up to RC.

I can understand the need for Beta to be representative of Release but personally, I don't see that there's going to be a web compat problem here and we probably don't need to go the EARLY_BETA... route. But I'll let MT and Mike weigh in here.

Flags: needinfo?(miket)

The point here about compatibility is central. The effect here is well understood. Release users will be subject to fewer connectivity issues. That this is not contiguous with our experience with Beta doesn't concern me for this feature.

However, if this might have systemic effects, then I'm happy to change 77 to use EARLY_BETA_OR_EARLIER instead. It's the matter of minutes of work.

Flags: needinfo?(mt)

It was left disabled in Chrome Beta as well. This thing is almost dead and it must be. It was reenabled on Stable, so desperate users can access every carelessly configured government website in this exceptional situation. If Beta and Nightly users find a broken server configuration, they should complain to the website (or to us, so we can reach out). It must be fixed asap. ;)
Check how the error page of looks in Chrome Beta (hostile <3) and how easy it is in Firefox Beta and Nightly to click on the prominent blue "Enable TLS 1.0 and 1.1" button.

Given (i) Chrome's behaviour and (ii) that we're (presumably) not going the EARLY_BETA_OR_EARLIER route for Beta 76 (given where we are in our cycle), then does it make sense to do it for Beta 77? Ryan, if this really is going to be a problem, then we can do this for 77 but perhaps not necessary.

Flags: needinfo?(miket)
You need to log in before you can comment on or make changes to this bug.