On 09/17/2008 11:55 PM, Ben Bucksch:
> Thunderbird currently has the SSL options: "Never" (plain), "TLS, if
> available", "TLS" (always), and "SSL" (always), for incoming IMAP/POP3
> and outgoing SMTP servers (with slightly different UI wording). TLS is
> basically SSL version 3.
>
> So far, "TLS, if available" is the default. What it does: It asks the
> server for its capabilities, and if the server reports/offers TLS
> ("STARTTLS" capability), it uses TLS, otherwise uses an unencrypted
> connection. This negotion happens on *every* connection (and that's the
> problem, see below).
>
> I assume that was chosen as default because the easiest to set up: the
> user doesn't need to know or try out whether the server supports TLS or
> not, and it will work either way, and if the server supports it, we'd
> use TLS.
>
> Or so we thought. SSL is supposed to protect against MITM (man in the
> middle) attacks and sniffing attacks, i.e. somebody else listening in
> the connection. However, if there really is a MITM attack going on, the
> attacker could simply reply without STARTTLS feature, causing
> Thunderbird to connect without encryption, and the attacker can easily
> listen in. The user would not be warned. It would be an active attack,
> passive sniffing is prevented, but still, listening without the user
> noticing is possible with this particular setting.
>
> I bring this up now, because this happened nation-wide with a mobile
> phone 3G ISP in Germany. They altered the IP traffic (!) on port 25 so
> that the STARTTLS capability string would not be reported to the client,
> causing all "TLS if available" clients to silently fall back to no SSL,
> without warning. (Motives are up for speculation, but government is
> quite possible, given recent laws for recording email correspondings.)
> It was only noticed because there are other users who have "TLS"
> (always) enabled and could not connect. And because it was nation-wide.
> If the attack happened only on a single user and that user has "TLS if
> available", he would not notice the attack. Therefore, I call this
> setting dangerous.
>
> I may have had some kind of valid reason in the past (ease of setup),
> but that's solved now with the new auto-configuration account setup
> dialog that we are working on. It checks, once during creation of the
> account, whether the server supports SSL or TLS. If it does, we
> configure that with the "always" setting, to prevent the above scenario.
> (I think it's highly unlikely and a bug, if a given server randomly
> switches between SSL support and no SSL support.) If the server does not
> support SSL (and also doesn't support password encryption?), we
> explicitly warn the user during setup. So, with the new setup code, we
> automatically pick the right setting.
>
> I don't think the "TLS, if available" is important anymore, and is
> dangerous. Therefore, I propose to remove it from the UI in the Account
> Manager as well. It could stay as backend pref for edge cases and
> existing users - the Account Manager UI would show the option only when
> it's already set in the prefs, and show a warning; otherwise, the option
> would simply be hidden.
>
> I worry about existing users, given that "TLS, if available" was the
> default so far. I would propose that TB3, when it sees such a setting in
> an existing account for the first time, informs the user, and runs a
> limited version of our probing code of the new setup dialog (just the
> backend code, different UI) to check whether the server supports TLS or
> SSL. If it does, it tells the user and asks him whether we can change
> the setting to TLS/SSL always. If the server does not support SSL, we
> inform the user (same as in the setup dialog) (and set a pref so that we
> don't run the migration code again).
>Yes, I'd support such an effort and proposal! +1 from me. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
