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).
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
