https://wiki.mozilla.org/Security:Renegotiation describes
> **the new default behaviour** that was introduced in experimental mozilla-central nightly versions on 2010-02-08
where the last step is
> - should the server (or a MITM) request **renegotiation**, Mozilla will terminate the connection with an error message
and then after talking about breakage ...
> The above defaults may break some client/server environments where a Server is still using old software and requires renegotiation.
mentions workarounds to reduce said breakage:
> In order to give such environments a way to keep using Firefox (et.al.) to connect to their vulnerable server infrastructure, the following preferences are available:
specifically talking about the first 2 prefs listed there, one allowing to specify a list of hosts "where renegotiation may be performed" and the 2nd one "completely disables the new protection mechanisms".
But both those prefs were removed in FF38, meaning that since then it's no longer possible to disable the default behaviour that is "should the server (or a MITM) request **renegotiation**, Mozilla will terminate the connection with an error message".
But all of this is about the **re**-negotiation part and not negotiation. And nowhere does it say "insecure" renegotiation, which, as I read it, means that FF will terminate the connection for any kind of **renegotiation**, safe or unsafe.
1201 controls the negotiation part:
> This pref controls the behaviour during the initial negotiation between client and server.
> If set to true, a Mozilla client will reject all connection attempts to servers that are still using the old SSL/TLS protocol and which might be vulnerable to the attack.
> Setting this preference to “true” is the only way to guarantee full protection against the attack.
I think "servers that are still using the old SSL/TLS protocol" actually means servers that **only** support the old protocols.
Servers still supporting those old protocols in addition to some new protocol versions should not be affected by this pref because FF will be able to negotiate to use one of the newer protocol versions.
Ergo lets fix the title and remove the line about renegotiation support because I think that's irrelevant.
ps. the sslpulse link is nice and I'd like to keep it somewhere but it doesn't really fit in 1201 IMO so I moved it to 1202.
- split geo related vs language/locale related
- rip out intl.locale.requested
- rip out intl.regional_prefs.use_os_locales
- add intl.charset.fallback.override
it rode the train in 69... after a bumpy ride in 68 where it was backed out. Note: it still has some issues. Suggest users wipe the site permissions once upgraded to 69
with `plugins.click_to_play` deprecated in FF69, no-one here is sure if `intervalInMinutes` still applies to Flash or even works, and no-one here cares about Flash. Happy to let Mozilla just keep restricting it more and more until it's deprecated in early 2020. Note: we already disable flash anyway in pref 1803.
- EFF has pretty pictures and stuff and explains the issues (replaces wikipedia which people can still search for)
- tor issue doesn't hold anything important (out it goes)
- moz wiki page I'll leave in for the bugzilla links if someone wants to research how it's all meant to work
I don't think we need a 4 yr old article to explain the concept of `.min` (or `.max`), it's pretty self explanatory (and SSL 3 is obsolete). Three lines of text culled, and one of the remaining http links eliminated as a bonus. Enjoy the saved bytes and mouse-scrolling.
- no need to enforce defaults (except the second cross-origin) = less items in prefs and about:support
- simplify header info
- add in that you need an extension for real control: i.e for most people, e.g I use uMatrix and have never can to whitelist anything. Kolanich has been on settings of 2 for years and only found one broken site: these are anecdotal and don;t reflect the real world: which is why the settings are pretty relaxed
- move the broken info out of header and onto the pref in a setup tag
- reference: https://github.com/ghacksuserjs/ghacks-user.js/issues/716#issuecomment-488527274
- thanks Kolanich and 🐈
- 0910 same as default for desktop. Android is the opposite, must be for a reason. Android is not really my concern.
- 1005: always been inactive: one less warning to deal with
- 1008: always been inactive. defaults are 60, 60
All of these are the same as default, checked back to ESR60 and Ff60. Except 2211 which is not considered an issue by TB for example, and it doesn't enhance anything IMO
Lets be consistent, we don't make min active as it alters your FP, and the risk is super low (updated the telemetry stat: down from 2% to 0.5%). Default max is now 4 anyway (don't care about ESR - they should be using the v60 archive).
Instead of being inactive, remove this. WebRTC is already blocked. And it can also be controlled by 1820. Redundant and does nothing extra for privacy, security etc
At best disabling the background update of gmp means not only an extra item for those who wish to use it (e.g widevine, netflix) to have to deal with, but also a time delay in getting the actual download. At worst, it could cause users to use an old dll (security risk).
I will leave it in, for now, but am seriously considering removing it, so don't cry if I do.
- SB: disabling it nothing to enhance privacy/security etc if changed from default
- SB: I will not provide the prefs or encourage users to disable these, especially given that there is a UI
- SB: the urls are redundant
- SB: note: the binary checks stays
- TP section is out of date (or soon will be), I'm not maintaining it, it has a UI and is best handled there
- explain pitfalls, add keyword tip, add setup tag
- given the searchbar is hidden by default in new FF installs, a lot of people could find this incredibly annoying (not being able to hit enter), including users who have changed their search engine - hence the setup tag
- these are not needed, you can view your cache in about:cache, or look at your `profile/cache2` folder (at least for portable Firefox), the remaining pref is enough to achieve the desired result
- browser.cache.disk.smart_size.first_run is set internally (for me it got automatically reset to modified false)
- the other two prefs are just more things for users to have deal with if they want to use disk cache
- Used setup-web since it relates to actual web pages, even though it doesn't break them
- Added the tag because it's an item that is likely to get attention / troubleshooting
- Added a warning tag to make the risk more apparent.
- Slight edit to the 2803 references
