Disable TLS 1.0 and 1.1 in Firefox Now!
Mozilla had planned to disable the insecure versions 1.0 and 1.1 of the TLS protocol in Firefox 74. Unfortunately, they reverted that planned change. This post explains how to disable insecure TLS versions yourself.
How to Disable TLS 1.0 and 1.1
The tl;dr version of this article:
- Open a new tab and navigate to
about:config - In the search box type
security.tls.version.min - Set the value to
3and click the save icon
Why Did Mozilla Revert the Change?
The release notes for Firefox 74.0 state the following:
We reverted the change for an undetermined amount of time to better enable access to critical government sites sharing COVID19 information.
Government websites from the digital stone age. Yuck!
Explanation of the security.tls.version.min Setting
The only documentation of the security.tls.version.min setting seems to be on mozillaZine, apparently a non-HTTPS site:
- 0
- The minimum required SSL/TLS version is SSL 3.0
- 1
- The minimum required SSL/TLS version is TLS 1.0
- 2
- The minimum required SSL/TLS version is TLS 1.1
- 3
- The minimum required SSL/TLS version is TLS 1.2
- 4
- The minimum required SSL/TLS version is TLS 1.3
How to Check Your Browser’s TLS Configuration
Head over to Qualys Labs. The topmost box of the report should look like this:
5 Comments
If you enable the TLS 1.0/1.1 and want to turn it off again, change the about:config setting `security.tls.version.enable-deprecated` from true(older TLS is allowed) to false. This can be verified with the Qualys Labs link where you will see “Yes” next to the older versions when enabled and “No” when disabled(assumed to be “default” or as-installed). Not sure how exactly this setting and “min”above reconcile differences.
Qualys Labs link was very helpful. Sharing wealth of knowledge.
It is good for Firefox to allow the user to modify the browser settings that will enable older security formats. There are still many reasons to have these older security formats accessible and essentially usable in the most modern of browsers.
It should be the client’s choice to determine what level of security is enough for any website they wish to surf.
Authoritarianism is a terrible way to do things.
Shame on you Chrome web browser! A warning page can be acceptable (as long as it can be disabled as well), but users should be able to surf the websites they wish to surf.
No
And it’s especially troublesome if the older TLS is from an admin console for a server that hasn’t had a firmware update since 2011. So what would be this blogger’s solution, throw out perfectly servicable hardware?
I want to update the semantics how to use a browser to a level which properly takes account of the RFC 8446+RFC 8996 (both are now valid and must be interpreted as kind of a “TLS law”). Since also the RFC 8446 should and must be taken for being the minimal required TLS security level. Server stacks still operating their TLS 1.2 basing upon RFC 5462 are meant to be called outdated. Everything else is old, or legacy, is obsolete, outdated, discouraged, deprecated, or is potentially or inherently weak or is already insecure per definition. By mid-2024 all my webbrowsers (all of them, as long as I can start these with parameters to restrict legacy TLS in all forms) only supports: ECDHE kex suites exclusively (plain RSA kex is disabled for good), but only those with either CHACHA20-POLY1305 or AESGCM. The CBC-blockchained suites are also disabled as well as all ff-DHE (DHE) kex’ed suites. This is what I call secure and so does e.g. Qualys SSLlabs (the client test result is all-green if you follow the abovementioned) or hardenize.com (for servers).