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

Status: RESOLVED FIXED

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

Description

[Martin Thomson [:mt:]]

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.

Comment 1

[Martin Thomson [:mt:]]

Attachment: Bug 1626495 - Re-enable TLS 1.0 for release, r?keeler

This effectively backs out https://hg.mozilla.org/mozilla-central/rev/1d07ac23cc5a95bd8247054acd87883fc4585738

MozReview-Commit-ID: 8tI373kNU62

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0475108a7a56
Re-enable TLS 1.0 for release, r=keeler

Comment 3

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/0475108a7a56

Comment 4

[Ryan VanderMeulen [:RyanVM]]

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?

Comment 5

[Thyla van der Merwe]

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.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 7

[Thyla van der Merwe]

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.

Comment 8

[Martin Thomson [:mt:]]

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.

Comment 9

[Darkspirit]

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 https://tls-v1-0.badssl.com:1010/ 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.

Comment 10

[Thyla van der Merwe]

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.