Closed Bug 1579285 Opened 2 months ago Closed 2 months ago

Offer to re-enable TLS 1.0 and 1.1 on TLS version failure

Categories

(Firefox :: Security, enhancement)

enhancement
Not set

Tracking

()

RESOLVED FIXED
Firefox 71
Tracking Status
firefox71 --- fixed

People

(Reporter: mt, Assigned: mt)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

As we start to disable TLS 1.0 and 1.1, people will encounter a SSL_ERROR_UNSUPPORTED_VERSION error more frequently.

Right now, we have an option to disable any custom prefs (#prefChangeContainer in aboutNetError.xhtml), but raising the minimum TLS version will eventually be a default in pre-release channels [*]. Adding an option to lower the version alongside the pref reset might give people some way of temporarily disabling those defaults.

This can (and should) be removed after March 2020 when we are committed to fully disabling old versions.

[*] If we are using Normandy to push a pref override as part of a progressive rollout, restoring defaults will be enough, but this would allow us to flip the default. Bug 1579270 will do that for Nightly.

How do you imagine such a toggle to work? Can't we just use the regular certificate exception mechanism? I suppose SSL_ERROR_UNSUPPORTED_VERSION is a netError? So certificate exceptions wouldn't be available? My only concern is that if you put a "fix it" button on certificate error pages that will permanently revert the pref you might as well not flip the pref in the first place.

[*] If we are using Normandy to push a pref override as part of a progressive rollout, restoring defaults will be enough, but this would allow us to flip the default. Bug 1579270 will do that for Nightly.

Under normal circumstances Normandy will change the default branch, so the above wouldn't be true in that case.

Yes, SSL_ERROR_UNSUPPORTED_VERSION is a netError and an indication of handshake failure. You don't get as far as seeing the certificate in that case, so none of the certificate-related stuff works.

I imagined that the "fix it" button would reset the pref if the value wasn't a default (I didn't realize that a Normandy experiment would change the default like that, so this half was pure pipe dream). If the value was at a higher default, such as it will be in Nightly soon, it would set a new pref that we would read alongside the usual pref. When we "remove" this override in March, we would stop reading that pref.

I think that as a general best practice you would want to give out per-site exceptions instead of offering a global switch to the user. Based on our experience, when the need is big enough (and at some point it will be for anyone) most users will override the security exception, making the intervention somewhat pointless. You can't convey to users that the decision they are making for this one site will affect their security on all other sites.

Could you imagine having a permission for this, that would be read by some part of our necko code which has access to permission manager? Since we can't whitelist individual certs (because, as you say, we don't have a cert yet), that seems like a doable alternative to a global override. It's a tiny bit of more work compared to just making a button that flips a pref, but IMO it's worth it.

Flags: needinfo?(mt)

So how does that work? Would we add a permission, maybe call it "old-tls", and then set that to "allowed" if the button is pressed. We can read that permission when connecting. We would remove that code in March. Presumably we would also need to purge the permission state.

We still need the pref for the purposes of Normandy rollout, from what I'm reading, so I don't know how that works with a permission after the root pref has been flipped (maybe we'd need another pref to disable this permissions check). Given that this is a short term thing, I'm not sure that the additional work, even if it is small, would be worth the additional effort. This will run for at most 5 months.

Right now, only changing a pref has a performance overhead, but this would add that overhead to every connection we make. Is it expensive to check permissions?

Flags: needinfo?(mt)

The intent of adding this pref is to allow us to change defaults for
security.tls.version.min for a progressive rollout of a TLS 1.0 and 1.1
deprecation. During that process, we'd like to offer the option to enable these
old TLS versions, without adding a pref override that would cause those versions
to remain enabled once we finish the rollout.

Those people who have triggered the override will be able to access TLS 1.0 and
1.1 sites until we eventually remove the code that respects this pref. What is
likely to happen is that this pref will remain in code past the end of our
rollout for part of a release cycle, plus maybe the next cycle depending on
how timing works out.

This pref is a simple boolean that we'll remove in March 2020.

As we roll out the TLS 1.0 and 1.1 deprecation, sites that don't support TLS 1.2
will show the neterror page. This adds a box to that page that shows in this
specific case. That box explains what is going on and gives an option to
re-enable TLS 1.0.

As mentioned, this will show alongside an option to reset TLS-related
preferences if any overrides are active.

Hitting the button will set the new pref to 'true' and reload the page.

Once the override is engaged, the option won't show, but that option to reset
preferences will show (as this is a TLS-related preference).

The intent is to remove this affordance in March 2020 as we formally move to
having TLS 1.2 the minimum version. All going to plan, this will only affect
prerelease channels, though anyone who has tweaked security.tls.version.* could
also see this.

Pushed by mthomson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/913652258fe6
Add pref to override minimum TLS version r=keeler
https://hg.mozilla.org/integration/autoland/rev/26e3ed3c1592
Offer to enable TLS 1.0 on neterror page r=johannh

Backed out 4 changesets (bug 1579285, bug 1579270) for browser-chrome failures at browser/base/content/test/siteIdentity/browser_deprecatedTLSVersions.js

Backout: https://hg.mozilla.org/integration/autoland/rev/dcfdecc355c0543125238cb465d81141c4913cf8

Failure push: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=26e3ed3c15925c8229a0be74d30f3fce6f0ae7f5

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=268700732&repo=autoland&lineNumber=1941

[task 2019-09-27T01:05:10.584Z] 01:05:10 INFO - TEST-START | browser/base/content/test/siteIdentity/browser_deprecatedTLSVersions.js
[task 2019-09-27T01:06:40.617Z] 01:06:40 INFO - TEST-INFO | started process screentopng
[task 2019-09-27T01:06:41.097Z] 01:06:41 INFO - TEST-INFO | screentopng: exit 0
[task 2019-09-27T01:06:41.102Z] 01:06:41 INFO - Buffered messages logged at 01:05:10
[task 2019-09-27T01:06:41.103Z] 01:06:41 INFO - Entering test bound
[task 2019-09-27T01:06:41.104Z] 01:06:41 INFO - Buffered messages finished
[task 2019-09-27T01:06:41.105Z] 01:06:41 INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_deprecatedTLSVersions.js | Test timed out -
[task 2019-09-27T01:06:41.106Z] 01:06:41 INFO - GECKO(1438) | MEMORY STAT | vsize 20975215MB | residentFast 1188MB
[task 2019-09-27T01:06:41.107Z] 01:06:41 INFO - TEST-OK | browser/base/content/test/siteIdentity/browser_deprecatedTLSVersions.js | took 90041ms
[task 2019-09-27T01:06:41.108Z] 01:06:41 INFO - Not taking screenshot here: see the one that was previously logged
[task 2019-09-27T01:06:41.109Z] 01:06:41 INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_deprecatedTLSVersions.js | Found a tab after previous test timed out: https://tls1.example.com/ -
[task 2019-09-27T01:06:41.109Z] 01:06:41 INFO - checking window state
[task 2019-09-27T01:06:41.110Z] 01:06:41 INFO - TEST-START | browser/base/content/test/siteIdentity/browser_geolocation_indicator.js
[task 2019-09-27T01:06:41.268Z] 01:06:41 INFO - GECKO(1438) | *** WIFI GEO: startup called.
[task 2019-09-27T01:06:43.271Z] 01:06:43 INFO - GECKO(1438) | *** WIFI GEO: Use request cache:false reason:No cached data
[task 2019-09-27T01:06:43.272Z] 01:06:43 INFO - GECKO(1438) | *** WIFI GEO: Sending request
[task 2019-09-27T01:06:43.272Z] 01:06:43 INFO - GECKO(1438) | *** WIFI GEO: sending {}
[task 2019-09-27T01:06:43.287Z] 01:06:43 INFO - GECKO(1438) | *** WIFI GEO: server returned status: 200 --> {"status":"OK","location":{"lat":37.41857,"lng":-122.08769},"accuracy":42}
[task 2019-09-27T01:06:45.268Z] 01:06:45 INFO - GECKO(1438) | *** WIFI GEO: Use request cache:true reason:New req. is GeoIP.
[task 2019-09-27T01:06:47.270Z] 01:06:47 INFO - GECKO(1438) | *** WIFI GEO: Use request cache:true reason:New req. is GeoIP.
[task 2019-09-27T01:06:49.273Z] 01:06:49 INFO - GECKO(1438) | *** WIFI GEO: Use request cache:true reason:New req. is GeoIP.
[task 2019-09-27T01:06:51.277Z] 01:06:51 INFO - GECKO(1438) | *** WIFI GEO: Use request cache:true reason:New req. is GeoIP.
[task 2019-09-27T01:06:53.273Z] 01:06:53 INFO - GECKO(1438) | *** WIFI GEO: Use request cache:true reason:New req. is GeoIP.
[task 2019-09-27T01:06:53.554Z] 01:06:53 INFO - GECKO(1438) | *** WIFI GEO: shutdown called
[task 2019-09-27T01:07:00.287Z] 01:07:00 INFO - GECKO(1438) | MEMORY STAT | vsize 20975347MB | residentFast 1189MB

Flags: needinfo?(mt)

Thanks. This is a problem with the patch for bug 1579270 rather than this one. I'll amend that patch.

Flags: needinfo?(mt)
Pushed by mthomson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4c234610246d
Add pref to override minimum TLS version r=keeler
https://hg.mozilla.org/integration/autoland/rev/b1146f29e20c
Offer to enable TLS 1.0 on neterror page r=johannh
Pushed by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/91a00d7fdb10
Fix prettier Eslint. r=me CLOSED TREE
Depends on: 1590935
You need to log in before you can comment on or make changes to this bug.