Closed Bug 473080 Opened 16 years ago Closed 14 years ago

Change "STARTTLS, if available" to "Insecure" (UI label)

Categories

(Thunderbird :: Preferences, defect)

Product:
Thunderbird
Component:
Preferences
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 3.0b2

People

(Reporter: BenB, Assigned: BenB)

Details

Some might prefer the label "opportunistic". :) Personally, I'd like to just get rid of the "if available" option, rather than renaming it, and add a "detect now" button, as suggested in the thread Ben cited above.
Nelson, this has already been discussed long ago, including these label names. We believe that we should, if anything, remove the "Never" option. We plan to do autodetection during account setup.
IIRC there might be problems with servers falsely claiming to support STARTTLS, so migrating users "up" might cause problems. That might be ok to do at account creation, but quite scary to do to existing accounts. I fully agree with Nelson we should get rid of the "if available" option altogether though. It's just false security. I don't like changing the label to Insecure. What's the purpose of that? It needs to be a label a person who knows the area could say "yes you should use that", or "no, don't use that" to. (Think admin, good isp support.)
Magnus, Nelson, please do not reopen the discussion. All this *has* already been discussed on the newsgroup, all these arguments. This bug does not ask to remove any option. It's merely about changing the label to "Insecure". FWIW, I agree that "if available" is not secure, but it's better than "Never", because it at least prevents passive sniffing. > What's the purpose of [changing the label]? To stop misleading users to think that "STARTTLS, if available" is secure. Again, *all* of that has already been discussed, in the very thread cited.
Assignee: mkmelin+mozilla → ben.bucksch
Oh please, you can't dismiss discussion about what's correct just because some thread on the newsgroups happened to discuss it. And I wouldn't call it a decision just because the discussion there died. Also, I think there are good reasons to allow a user to choose "no encryption", and not upgrade via STARTTLS if available. You might be using tb over vpn, ssh tunneled, using IPSec or have other means to know you're already secure. Just dropping the "if available" option makes all this discussion moot, of course.
I never saw the discussion on the newsgroup. IMHO an "Insecure" option is a very BAD label. Consider: "Use secure connection" -> "Never" Ok, that's good, I can select never and know what I'm going to get. "Use secure connection" -> "Insecure" Well this can't mean I'm going to be insecure, because what is the never option for? So therefore it is a insecure connection that is secure? IMHO this will just confuse users even more than the current option set.
Security-technically, this option protects against passive sniffing, if the server supports STARTTLS, but not against a MTIM attack. I just don't know how to get *that* past to users. But it is more secure than "Never", but well, not reliable security. Because it isn't reliable security, and it's not obvious (even I didn't realize for a long time), it's important that the label be changed to something that makes it very clear to the users that they cannot rely on their connection being secure. OTOH, I disagree with Magnus that the option should be removed entirely, because it does prevent passive sniffing, and it can be enabled in all cases where you'd use "Never" (apart from very few edge cases - even in a VPN, I'd use SSL, because the company's intranet could also be sniffed and indeed is in practice quite often). Therefore, if we remove any option, I'd remove the Never option. But it seems we cannot agree on removing any option just yet, so I propose to just rename "STARTTLS, if available" to something very close to "Never".
FWIW, here's what I would do, if it was all up to me: I'd remove the "Never" option from the UI, but allow it in backend prefs for advanced users. "STARTTLS, if available" is renamed to "No" in the UI. Therefore, all users get minimal protection, but do not assume that they are secure, which is correct. Those people who have a real technical problem with STARTTLS can disable it in the backend prefs.
Why would it be useful to check for each connection? It's not like the server capabilities would (almost) ever change. If we detect that STARTTLS is supported, it's likely to be that way forever, so a one time move over gives people the best security and predictable behaviour. (If we can do it of course.)
There are misconfigured mail servers that claim to offer STARTLS but which cannot successfully complete a handshake. It is necessary to select "NONE" to be able to successfully connect to them. I'll bet $$ that some of our users depend on that feature (knowingly or not). So, IMO, we should not eliminate "NONE" as a choice, regardless of what we call it. I agree with Ben's comment that about the "if available" option, that "it's important that the label be changed to something that makes it very clear to the users that they cannot rely on their connection being secure.", but I'd prefer to eliminate that option (which most users simply won't understand, not with any label) and instead give them a "detect now" button that sets the choice to one of the 3 unconditional options. I'd add that any detection, whether manual or auto, must do more than simply test for the capability. It must actually attempt to complete a handshake. Again, this is because of servers that claim to offer STARTTLS, but don't.
A couple of remarks: I'd assume that the "if available" method should be obsoleted when bug 422814 lands and a definite probing of the server's capabilities is sought for during account setup, or not? After all, the current option is somewhat of a "lite" version of the complete auto-configuration. Secondly, I see some inconsistency in the discussions on the labeling of those options. There has been bug 185662 for SMTP, which changed "SSL" to the more accurate "SMTP-over-SSL" and "TLS" to "STARTTLS" for the outgoing settings. Asking here for a simplification of "STARTTLS, if available" to something as fuzzy as "Insecure" is contrary to the change in the SMTP settings. The labels should be consistent among dialogs to minimize user confusion. Personally, I'd like Neil's suggestion in bug 350314 comment #34: > * No encryption > * Request STARTTLS (obsolete) > * Require STARTTLS (secure) > * Require SSL (secure) Maybe with "xxx-over-SSL (secure)" as the last option. This would be intuitive and nevertheless unambiguous.
Though unless I misunderstood something, it's not just SSL, but SSL v3 or TLS, but we don't care which. Anyway, since we change it we should make it technically correct. I don't think bug 422814 touches existing accounts, but maybe it could make it fairly easy to drop the "if available" option. Bienvenu?
right, bug 422814 does not touch existing accounts. I'm not sure how you easily drop the "if available" option, without trying both tls and non-tls somehow. You'd need to write protocol specific code to detect the "if available" option, and then set the connection type to whichever worked. I'd say just drop it from new accounts and go from there.
The term "SSL" without any qualifiers includes all versions of SSL, including SSL 2 (really 0.2), SSL 3.0 and SSL 3.1 which is also known as TLS. STARTTLS is not TLS, it's not SSL. It's a feature of the IMAP, SMTP, and POP protocols that may be used to cause those protocols to launch SSL 3.x in the middle of a connection. It doesn't care about the version of SSL, except that version 2 is disallowed, by convention.
I don't think the Insecure option is a good choice for the label. It doesn't make sense and isn't what we want people to do; our design must be responsible for both angles. This has gotten lots of discussion time, but I believe the best path forward is to remove the 'if available' option all together. Perhaps through about:config as a back-compat users can set the 'if available' option but I don't think it's a viable route and not something I think we want to continue to deal with in the future. Upgrading users should get STARTLS or fall back to Never; the fall back users require some warnings, but I believe this is what we have to do.
Just landed bug 350314, and with that users can't ever select "if available" - though it's used and shown if they had it to begin with. Since we don't have the code to reliably upgrade to TLS, and dropping to none would be less secure, I assume this bug is now wontfix.
Flags: wanted-thunderbird3? → wanted-thunderbird3-
Whiteboard: wontfix?
Well, not so much "since" that, but anyway.
(In reply to comment #15) > This has gotten lots of discussion time, but I believe the best path forward is > to remove the 'if available' option all together. Perhaps through about:config > as a back-compat users can set the 'if available' option but I don't think it's > a viable route and not something I think we want to continue to deal with in > the future. Upgrading users should get STARTLS or fall back to Never; the fall > back users require some warnings, but I believe this is what we have to do. I would also like this rearrangement. This would be the safest way for all TB3 users. One of the most frequent webmail provider in germany recommend (!) on their web page to use "TLS, if available". So I'm sure there are a lot of users at the moment who are using this insecure method. http://img.web.de/v/mail/pdf/pop3_thunderbird.pdf http://img.web.de/v/mail/pdf/imap_thunderbird.pdf The solution from bug 350314, to hide it if it isn't selected is very smart, but this doesn't work if the user think "TLS, if available" is secure (because it's recommended from the provider) and do not change it.
Something about the choices needs to be available in the Help for TB v3. I just set up a new profile for 3.0b2 and immediately noticed that my choices were 1( different than in V2; and 2) it is less clear what I should choose. In the past I always chose "Use TLS if available" except in the case where an ISP notified all users that they must use SSL. I'm not expert in these aspects of security, but I am a much more informed user than most and if I don't know what to choose in the new environment then I'm confident that most users won't know either. So some documentation in the Help to help people that are migrating as well as new users seems pretty important.
Fixed as part of bug 525238.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: wontfix?
You need to log in before you can comment on or make changes to this bug.