Some notes on Firefox's interstitial warning for old TLS versions

April 25, 2020

Firefox, along with all other browsers, are trying to move away from supporting older TLS versions, which means means anything before TLS 1.2. In Firefox, the minimum acceptable TLS version is controlled about the about:config preference security.tls.version.min; in released versions of Firefox this is still '1' (for TLS 1.0), while in non-release versions it's '3' (for TLS 1.2). If you're using a non-release version and you visit some websites, you'll get a 'Secure Connection Failed' interstitial warning that's clear enough if you're a technical person.

The bottom of the warning text says:

This website might not support the TLS 1.2 protocol, which is the minimum version supported by Firefox. Enabling TLS 1.0 and TLS 1.1 might allow this connection to succeed.

TLS 1.0 and TLS 1.1 will be permanently disabled in a future release.

It then offers you a big blue 'Enable TLS 1.0 and 1.1' button. If you pick this, you're not enabling TLS 1.0 and 1.1 on a one-time basis or just for the specific website (the way you are with 'accept this certificate' overrides); you're permanently enabling it in Firefox preferences. Specifically, you're setting the security.tls.version.enable-deprecated preference to 'true' (from the default 'false').

As far as I've been able to see, the state of this '(permanently) enable deprecated TLS versions' setting is not exposed in the Preferences GUI, making its state invisible unless you know the trick (and even know to look). Perhaps when Mozilla raises the normal minimum TLS version in a Firefox release, they will expose something in Preferences (or perhaps they'll change to do something with per-site overrides, as they do for TLS certificates). In the mean time, if you want to find out about websites using older TLS versions through your normal browsing, you'll need to remember to reset this preference every time you need to use that big blue button to get a site to work.

(You might be doing this in Nightly or Beta, although probably you should avoid Nightly, or you might be doing this in a released version where you've changed security.tls.version.min yourself.)


Comments on this page:

From 157.52.7.136 at 2020-04-25 07:06:05:

TLS 1.0 and TLS 1.1 will be permanently disabled in a future release.

I certainly hope not. We have a lot long-term (embedded) legacy systems (e.g., HVAC) that will probably not be getting updates any time soon. I guess one option would be to have a stand-alone / portable instances just for that.

The plan was announced with approximately 2 years planned: All major browsers [to] drop TLS 1.0 and 1.1 in 2020

Mozilla postponed their initial plan to drop it in Firefox 74; at the time of writing, the current site compatibility note indicates a plan to leave it enabled through Firefox 77 at minimum.

Chrome currently plans for removal in Chrome 84.

I realize this doesn't really help. It's more like the Vogon saying over the PA system, "All the planning charts and demolition orders have been on display in your local planning department in Alpha Centauri for fifty of your Earth years…" But I hope it's informative, at least.

One solution for legacy systems would be to place a reverse TLS web-proxy in front of the legacy system that talks TLS 1.0 to the old system and modern TLS 1.3 to the browser. nginx can do this, but also something simple like stunnel would work.

It also works the other way, accessing modern TLS enabled server from legacy client software (but be aware of the security risks of using legacy software in the Internet)

By James (trs80) at 2020-05-03 10:48:39:

Keeping an old browser around for accessing out-of-date systems is a pretty common thing for a sysadmin to do.

Written on 25 April 2020.
« Accepting TLS certificate hostnames based on IP address checks is not safe
Looking back at DTrace from a Linux eBPF world (some thoughts) »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Apr 25 00:05:20 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.