Privacy Issue #2932
[iceweasel-hardened-preferences] Kill insecure connections
Insecure connections are dead long time, but browsers for some reason are too slow to even use a warning on them.
Consider switching the following config prefs in hardened preferences:
`security.tls.version.min` to 3 (anything older than TLS 1.2 should be disabled; re-enabled because of stupid government system administrators, should never happen)
`security.mixed_content.upgrade_display_content` (upgrade mixed "content")
`browser.preferences.exposeHTTPSOnly` (enable HTTPS-only display, might be unnecessary on Firefox 83 release)
`dom.security.https_only_mode` and `dom.security.https_only_mode_ever_enabled` to force HTTPS-only mode
`security.insecure_connection_text.enabled` text for insecure connections.
If we were discussing this being applied generally I'd definitely say no (will explain below). As this is about "Hardened" I'd say yes but with strong warnings.
The problem with this idea. Especially for iceweasel, is that there is no easy way to back out of it temporarily and that is an issue because MANY routers/NAS/IoT/Etc. things Do not have HTTPS on their LAN side management interfaces. Or if they do they are often signed with a self signed cert. The suggested setting will result in people not being able to talk to such devices. In fact the current (default) Iceweasel setting often make it much harder then it should be.
So For Hardened - Yes but with a warning that it will cause the above issues. And that dealing with the above issues is the responsibility of the now informed user.
Updated by grizzlyuser 11 months ago
There's a more general issue with preferences in Firefox-based browsers. They are disconnected from the actual code that depends on them. Codebase changes quite frequently, and there's no guarantees that any given preference will be there in the next release. If it's gone, there'll be NO notification to the user about that. So in the end it may just give false sense of security and/or privacy.
Security/privacy related settings usually come at a price of convenience or breakages of some functionality. Also, not everybody has the same threat model. Users must make informed decisions about each and every pref in their setup. Just setting new default values for these prefs is risky, if done without any clear explanations in the UI. Because, as freemor noted, it can introduce issues in some cases.
These preferences also have to be covered by tests that make sure that they really work at any given moment.
Global community should work on building a polished solution. For example, Tor Browser looks like the most suitable one. It has some issues with FSDG, but less than upstream Firefox, because some of them like DRM are (at least partially) resolved by the Tor Project. These issues can be resolved either in upstream Tor Browser (better), or by forking it (worse).
TB has some specific controls in the UI that help users with those informed decisions about security/privacy. And also a lot of customization under the hood, like support for alt-svc headers that let properly configured clearnet websites to upgrade requests seamlessly to .onion ones.
grizzlyuser good point on the about:config settings changing without notice. And I agree that a more permanent replacement where security is baked and tested up stream might be a better idea.
Also Doing so would separate the "hardened" browser from the system default iceweasel.
Updated by sdfoijsaodif 11 months ago
HTTPS only mode was implemented in Firefox 83 so I don't think this option will change. `browser.preferences.exposeHTTPSOnly` can be removed from the list on 83 upgrade.
They said TLS 1.0 and 1.1 will be disabled when this COVID-19 ends (if it will ever end).
Browser developers are too slow at deprecating HTTP, but I don't think they will remove insecure warnings. I think they will enable them in the future, who knows when.
Updated by bill-auger 11 months ago
anyways, networking protocols are not the sort of technology that
can be deprecated or obsoleted by proclamation of any authority -
whichever protocols are at the "lowest common denominator"
between communicating devices, is what must be used; regardless
of who recommends against them
for examples: i can remember people pointing out that some
hot-spots ("captive portals") will only pass HTTP traffic -
logins for consumer-grade networking devices (routers, hobby
boards, and other whats-its) could be a similar situation