This may end up as a won't-fix, but filing it per today's meeting discussion: 14:13 - rsx11m - "security.tls.version.fallback-limit is new. So we need to add the latter to our preferences UI." 14:13 - rsx11m - didn't we say last time (6 weeks ago) that those can't be tied together? 14:13 - rsx11m - anyway, I don't think we have a bug for that anywhere 14:14 - IanN - could you check and raise if need be? 14:14 - rsx11m - but then, the SSL prefpane if full enough already to add yet another checkbox... 14:15 - rsx11m - the workaround may be to enable SSL 3.0 and to disable all TLS 1.x. then the newer protocols won't be tried first and SSL 3.0 is chosen directly (not as a fallback) if needed for a specific site 14:15 - rsx11m - (at least that's my understanding how it worked) 14:16 - Ratty - rsx11m: in any case we can always file a bug. Shuffling the prefpanes can be discussed there. 14:16 - rsx11m - either way, it will be tough for a user to figure that out... 14:16 - Ratty - rsx11m:yeah
For reference: That pref was introduced with bug 1083058, initially disabling SSL 3.0 only. Bug 1084025 disabled the fallback entirely by setting security.tls.version.fallback-limit=3.
Bug 1085138 (POODLEBITE) [META] Sites broken due to reliance on a security protocol that was obsolete last millennium, and also bug 1084025 dependencies list some affected websites for which this pref may need to be modified by the user.
There has been some action in bug 1106470 - Drop SSLv3 support entirely. Removal of SSL 3.0 support would likely render the issue here mood (unless we are running into a similar issue with TLS 1.0 no longer being enabled by default and no longer allowed to fall back to in the near future).
(In reply to rsx11m from comment #3) > (assuming the default allows only "secure" fallbacks). There are no such "secure" fallbacks. TLS version fallbacks are inherently insecure. If the server is not buggy, we don't have to (and should not) do any fallbacks at all even if the server supports only lower versions than TLS 1.2. (In reply to rsx11m from comment #4) > There has been some action in bug 1106470 - Drop SSLv3 support entirely. > Removal of SSL 3.0 support would likely render the issue here mood (unless > we are running into a similar issue with TLS 1.0 no longer being enabled by > default and no longer allowed to fall back to in the near future). The option would be still useful for TLS version intolerant servers (see bug 1126620 blockers). Some servers are unlikely to be covered by the built-in whitelist.
Fallbacks within TLS has been disabled entirely by default, given that it's a dangerous thing to allow that. On the other hand, bug 1084025 comment #116 suggests that users are running into issues with intolerant servers. Neil, what's your opinion? If that's a feature where you would post a warning dialog with 3-page disclaimer first before allowing it to be enabled, maybe it shouldn't show up on the prefpane? On the other hand, it's difficult to discover what pref is involved and how to change it. Per today's status meeting, IanN may look into the error message we get when meeting a bad server, thus maybe getting some improvement here.
(In reply to rsx11m from comment #6) > Fallbacks within TLS has been disabled entirely by default, given that it's > a dangerous thing to allow that. On the other hand, bug 1084025 comment #116 > suggests that users are running into issues with intolerant servers. > > Neil, what's your opinion? If that's a feature where you would post a > warning dialog with 3-page disclaimer first before allowing it to be > enabled, maybe it shouldn't show up on the prefpane? > > On the other hand, it's difficult to discover what pref is involved and how > to change it. > > Per today's status meeting, IanN may look into the error message we get when > meeting a bad server, thus maybe getting some improvement here. I think this pref might be using a sledgehammer to crack a nut. On the other hand, depending on the error you get when visiting an intolerant site, it might be possible to add some UI to whitelist that site (see bug 1114816).
Yes, I'd agree and rather tend to won't-fix this bug as is in favor of making the whitelist accessible. Somewhat problematic is the detection of an intolerant server. I managed to improvise a server that supports SSL3 only and tried to connect, giving me just a "Secure Connection Failed: The page you are trying to view cannot be shown because the authenticity of the received data could not be verified." (nssFailure2 in mozilla/dom/locales/en-US/chrome/netError.dtd). That's rather generic, not really indicative for a protocol/version issue, thus it may be tricky to trigger a whitelist dialog as needed.
I managed to tweak the server to offer only 3DES with TLS 1.x, but not AES, thus prompting an intolerant situation when TLS 1.0 is attempted. With the TLS 1.0 box checked, I get a proper connection; if it's not checked, 1.1 or 1.2 fail given that 3DES was deprecated in these versions. I'm getting now nssFailure2 in about:neterror as well, but with a more specific "unsupported protocol" message and code. Thus, there may be a way to grab that, but it still likely would have to happen in the NSS or Toolkit code somewhere. The "lite" version would be to allow editing of the whitelist from the UI, e.g., the Data Manager, without automatically prompting it when an intolerant server is encountered (less discoverable again).
So, where do we want to go with this? Bug 1215796 has removed the static fallback list, which will become effective with the next SeaMonkey 2.41+ release; security.tls.insecure_fallback_hosts is still around but now empty. TLS 1.0 is the maximum fallback either way with SSL 3.0 removed a while ago. If at all, we could have a "Fallback..." button in the UI which opens a generic Add/Edit/Delete dialog tied to the security.tls.insecure_fallback_hosts prefs.
WONTFIX per discussion in today's status meeting, especially since we'll need the space for TLS 1.3.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.