SSL Preference Pane Changes

[therube]

That's better.
Though I do still need to really think about it to (kind of) understand it.

Last shot should have 1.0 checked? Or not?
Since 3.0 & 1.1 require 1.0.
But then I find "oldest" & "newest" confusing too.

So ...

3.0 & 1.0
1.0 only
1.0 & 1.1
1.1 only
3.0 & 1.1 (& 1.0 also, but not specifically shown, but seemingly should be?)

In any case, for me checkboxes are far clearer.

[rsx11m]

Last shot should have 1.0 checked? Or not?
Since 3.0 & 1.1 require 1.0.
But then I find "oldest" & "newest" confusing too.

It's a "from ... to ..." functionality, thus indeed 1.0 is implicitly given. This might have been clearer in the very first design using menulists rather than radiobuttons (which Ian feedback-'ed):



The labels can be more verbose here given that the widgets themselves need less horizontal space. Neil apparently would be willing to revisit that approach if it takes up less height (i.e., putting both on the same line), but then you'd loose that advantage.

I agree that the checkboxes are definitely the least ambiguous when it comes to conveying which protocols can be used (and won't take up more space than the 1-line menulists).

[-Px-]

To address the possible ambiguity in what "grayed-out box" means, I've come up with a compromise where the box is still disabled and grayed, but the label itself stays "normal" (which corresponds to the screenshot therube has posted from the other application, thus I think that would be a good metaphor)

This one looks best for me

[rsx11m]

Interestingly, Neil didn't quite like the tri-state checkboxes, but gave it a ui-r+ anyway (along with the 2x3 disabling radiobutton version posted at the end of the previous page). I guess it's up to Ian now to pick the winner...

[rsx11m]

The checkbox version won, so this is what it will look like once the patch has been checked in:


(repeated here as the first posting is hidden on the previous page...)

[therube]

Works for me.
Thanks for your work .

Now I've just got to figure out just which protocol(s) to use .

[rsx11m]

Patch checked in already, thus you should see it with tomorrow's trunk nightly.

It appears that the default maximum was left at TLS 1.0 and not bumped to TLS 1.1 on purpose to wait for that version to be more established. On the other hand, as TLS 1.2 is coming up soon, the default will likely be bumped to 1.2 directly once it's considered to be safe.

You can try setting it to TLS 1.1; if it doesn't work with a specific server, it should fall back to 1.0 (hopefully not to SSL 3.0). I don't know of a way though how you can figure out which version is actually used.

[rsx11m]

Now I see why TLS 1.1 isn't enabled by default yet:

• Bug 839310, Add insecure fallback from TLS 1.1 -> TLS 1.0

Meaning, while the TLS 1.1 protocol itself is supported already, falling back to 1.0 if it fails is not. Thus, if you enable TLS 1.1, it may be the only version attempted for now, rather than using the older versions if the server doesn't support it.

[rsx11m]

I've added a Security.tls.version.* article to the KB to help understanding what those prefs do (that's more from the backend perspective, but can be linked to from the "SSL is disabled" article which likely users will look up first if they run into issues or want to know more).

[rsx11m]

It appears that the default maximum was left at TLS 1.0 and not bumped to TLS 1.1 on purpose to wait for that version to be more established. On the other hand, as TLS 1.2 is coming up soon, the default will likely be bumped to 1.2 directly once it's considered to be safe.

For those following bug 733647, a patch has been approved there to indeed bump the default for the maximum version to TLS 1.2, where it is not clear at this time if they'll wait for bug 839310 adding the fallback (thus effectively breaking TLS by default for servers which aren't supporting TLS 1.2 yet).

I've opened bug 884449 today to add the 4th checkbox and will watch the development in NSS for the case we'll need to get this in before the next merge on Monday.

[rsx11m]

Patch posted and reviews requested, some forth-and-back in the TLS 1.x fallback patch, thus let's see what happens next and if any last-minute actions will be necessary over the weekend.

[rsx11m]

The patch has been approved already and is ready to be checked in (as permitted whatever the current situation on comm-central is). Even if the checkbox is available after this is pushed, I'd recommend caution in switching TLS 1.2 on given that there is still quite a bit of activity (and things left to do) in the dependent bugs. It won't become the default until bug 733647 checks in (which may still happen for the 24.0 cycle).

[rsx11m]

The TLS 1.2 box should show up in tomorrow's nightly builds (and in aurora on Tuesday, after the merge) while the default thus far hasn't been changed from TLS 1.0 to TLS 1.2 in the backend.

[rsx11m]

FWIW, bug 480514 Implement TLS 1.2 (RFC 5246) has been resolved as FIXED yesterday, thus apparently the TLS 1.2 implementation itself is now complete except for the TLS 1.0 fallback and possibly some other remaining bugs.