1123673 - Consider exposing security.tls.version.fallback-limit in SSL prefpane to accommodate SSL 3.0 legacy sites

Status: RESOLVED WONTFIX

(SeaMonkey :: Preferences, defect)

Description

[rsx11m]

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

Comment 1

[rsx11m]

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.

Comment 2

[rsx11m]

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.

Comment 3

[rsx11m]

The "least painful" way to offer this in the prefpane is probably adding a simple checkbox rather than yet another set of radiobuttons with protocol versions. Thus, something like

Enable: [ ] SSL 3.0  [x] TLS 1.0  [x] TLS 1.1  [x] TLS 1.2
        [ ] Allow insecure fallback

Upon opening of the dialog, the box is not checked if no user-defined value exists and checked if it does. It is disabled for security.tls.version.min == security.tls.version.max.

When checked, any change to security.tls.version.min in the first row automatically applies to security.tls.version.fallback-limit as well. When unchecked, the user-defined value is cleared (assuming the default allows only "secure" fallbacks).

This would require some more JavaScript magic but seems to be most intuitive and sufficiently general. It still may require to split the SSL prefpane or add an "Advanced" subdialog given that an additional line may exceed the vertical limit of this prefpane.

Comment 4

[rsx11m]

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).

Comment 5

[Masatoshi Kimura [:emk]]

(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.

Comment 6

[rsx11m]

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.

Comment 7

[[e-mail]]

(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).

Comment 8

[rsx11m]

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.

Comment 9

[rsx11m]

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).

Comment 10

[rsx11m]

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.

Comment 11

[rsx11m]

WONTFIX per discussion in today's status meeting, especially since we'll need the space for TLS 1.3.