"TLS, if available" in Thunderbird
Ben Bucksch
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).
Eddy Nigg
Yes, I'd support such an effort and proposal!
+1 from me.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Steffen Wilberg
> 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).
When the "TLS if available" code runs and succeeds with establishing
TLS, it should just silently switch to "always TLS".
It's safe to assume that users prefer encryption, once they know that it
"just works".
Steffen
Kaz Sasayama
non-TLS-enabled version to TLS-enabled one, the user should be warned
at least once to change the pref for better security IMHO.
Nelson Bolyard
> 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.
Damn! Those old wrong labels are STILL in use?
Even after bug 185662 was allegedly fixed?
Please read all the way through bug 185662 and bug 350314. Those bugs will
explain that the mode labeled as "TLS" is actually "STARTTLS", which is
something very different. I've been trying to get those labels replaced
with something better for years.
Bug 350314 also explains that the "TLS if available" option should be
called "StartTLS, unless there's an attacker".
That option should just go away. It is trivially attacked. Even if
the server really does offer TLS, an attacker can easily fool the
client into thinking that the server does not, so the client will not
use TLS even though it is available.
The idea you proposed, of using "TLS, if available" as a way to just
cause the one-time automatic detection and account configuration has
been proposed in several bugs, including bug 350314 comment 12.
It was rejected four months ago because of an alleged string freeze.
The major news you've added in this email is that this exploit is now
being massively utilized. That information should go into bug 350314.
Sorry for my bad attitude. I've been calling attention to this issue
for months, and getting at most a ho-hum response. Maybe now, the
news that this is being massively exploited will finally get it some
attention.
Johnathan Nightingale
> 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).
I think it would be helpful to have Bryan comment in here since I know
the account creation process is being dramatically revamped in TB3.
We had a brief conversation about it yesterday though, where I came to
a slightly different conclusion, that I think is nevertheless
compatible. I would be interested in your thoughts.
My suggestion was that:
- We should not expose STARTTLS in the set up process, since it will
not be meaningful to most users, and risks deceiving the others into
assuming they are secure when they aren't, BUT
- We should turn it ON by default on non-secure connections, because
even though we know full well that the connection is subject to
subversion, we have a nearly-free way to marginally reduce the attack
surface in the background.
- And yes, there should be some way to turn it off in case you have
an ancient or broken server that's confused by STARTTLS requests
To be clear here: I think at no time should we suggest that STARTTLS
is "secure", or "safer", or better in any way, really, in the UI. I
think the nuance there ("encrypted, but subject to downgrade attacks")
is not something that is reasonable to force our users to understand.
But I do think that if we have an opportunity to make things better in
the background while still marking the server as an unsecured one, it
makes sense to do so. To my mind, it's akin to the question of HTTP
Basic Auth vs. Digest Auth. It's not really worth it to me to explain
the differences in the UI there, it's not at all ironclad, but we
might as well use the slightly better technology if it exists.
Am I wrong, here? Is there a hidden cost to STARTTLS that makes it
decidedly worse than vanilla, unencrypted traffic, other than the
false sense of security it creates?
Cheers,
Johnathan
PS - And yes, whether or not my suggestions above are riddled with
holes, I agree with Nelson that the labelling on the prefs, once
thusly-re-arranged should really reflect what's actually happening. I
think more about this than most people, and I would still draw the
wrong conclusion from a checkbox that said "TLS", in this case.
---
Johnathan Nightingale
Human Shield
joh...@mozilla.com
Jean-Marc Desperrier
> [...]
> - We should turn it ON by default on non-secure connections, because
> even though we know full well that the connection is subject to
> subversion, we have a nearly-free way to marginally reduce the attack
> surface in the background.
> - And yes, there should be some way to turn it off in case you have an
> ancient or broken server that's confused by STARTTLS requests
I'm happy we can agree on this point, it makes me hope someday you'll
see the light about why the current handling of SSL errors in Fx3 is far
from perfect (first by realizing that there's *not* only the proponents
of self-signed certs in that camp).
The options should read :
[ ] require STARTTLS
[ ] disable STARTTLS
With none of the two enabled by default.
Getting "require STARTTLS" automatically enabled if the initial
connexion was succesfully in STARTTLS mode would be good.
Maybe "require secure mode (STARTTLS)" and "disable secure mode
(STARTTLS)" would be even better for the average user ?
Stefanos Harhalakis
> The options should read :
> [ ] require STARTTLS
> [ ] disable STARTTLS
>
> With none of the two enabled by default.
>
> Getting "require STARTTLS" automatically enabled if the initial
> connexion was succesfully in STARTTLS mode would be good.
>
> Maybe "require secure mode (STARTTLS)" and "disable secure mode
> (STARTTLS)" would be even better for the average user ?
If it goes like this I'd suggest something like "Require encrypted data
transfer" and "Disable encrypted data transfer" as it is more accurate and
equally, if not better, understood (Just "Require encryption" may be
misunderstood as an e-mail encryption method or something like that).
Eddy Nigg
> I'm happy we can agree on this point, it makes me hope someday you'll
> see the light about why the current handling of SSL errors in Fx3 is far
> from perfect (first by realizing that there's *not* only the proponents
> of self-signed certs in that camp).
The worlds of web and mail are inherently different, as transport of
mail may or may not be encrypted to and from the server - transport
isn't limit to the client-server connection.
So lets not confuse the meanings between those two!
In order to secure mail correctly, S/MIME certificates can be used. TLS
connections to mail servers simply prevents some sniffing and to some
extend can assure that you are talking to the right server. It's not
more than that.
> The options should read :
> [ ] require STARTTLS
> [ ] disable STARTTLS
>
> With none of the two enabled by default.
>
> Getting "require STARTTLS" automatically enabled if the initial
> connexion was succesfully in STARTTLS mode would be good.
I think this is a good idea (The wording can be improved).
Boris Zbarsky
> In order to secure mail correctly, S/MIME certificates can be used. TLS
> connections to mail servers simply prevents some sniffing and to some
> extend can assure that you are talking to the right server. It's not
> more than that.
Most importantly, from my point of view, they protect your password from
being sniffed. This is important because often that password is shared
across other sites as well (various LDAP-like setups, for example).
-Boris
Eddy Nigg
You are absolutely right!
Ben Bucksch
instead of "no SSL", and to never configure "No SSL" (unless manually
requested), and to treat "TLS, if available" like unsecured in the UI.
I can agree with that.
Johnathan Nightingale
That's it precisely. And thank you for expressing it so succinctly.
Cheers,
Johnathan
Ben Bucksch
> On 19-Sep-08, at 7:39 AM, Ben Bucksch wrote:
>
>> I think you are suggesting to (by default) use "TLS, if available"
>> instead of "no SSL", and to never configure "No SSL" (unless manually
>> requested), and to treat "TLS, if available" like unsecured in the UI.
>>
>> I can agree with that.
>
> That's it precisely. And thank you for expressing it so succinctly.
Great.
The important part is "treat 'TLS, if available' like unsecured in the
UI", though. We can't say "Automatic" or anything else that suggests
that people may be secure (because they not, even if STARTTLS works at a
given moment, because it may not work in 5 minutes).
How do we do that (in the Account Manager), and still differentiate this
option to the manually turned off SSL ("Never")?
The previous suggestions [ ] require TLS [ ] disable STARTTLS, i.e. two
checkboxen, don't work, at least not as-is, because we also have the
difference between SSL and TLS (TLS is the newer version of SSL).
Currently, we have a radio box.
If we want to keep that, we'd have to use
Use secure connection:
( ) Never (o) Insecure ( ) SSL ( ) TLS
where "Insecure" is the former "TLS if available".
Stefanos Harhalakis
> The important part is "treat 'TLS, if available' like unsecured in the
> UI", though. We can't say "Automatic" or anything else that suggests
> that people may be secure (because they not, even if STARTTLS works at a
> given moment, because it may not work in 5 minutes).
>
> How do we do that (in the Account Manager), and still differentiate this
> option to the manually turned off SSL ("Never")?
I believe that kmail's approach works better (?) in this case w.r.t. the
end-user. It doesn't alter its behaviour at run-time but it has a 'check what
server supports' button. This way, the auto-detection is performed once
(during configuration) and the user is immediately notified.
Based on other comments, I don't see how an altering behaviour may be
considered secure. Perhaps an upgrade-only behavior (for the automatic
option) would be more secure: If it ever detects STARTTLS support then it
would just upgrade to TLS and keep it like that.
Also, all these could be replaced by a notification box that is shown whenever
the user selects no encryption but TB detects STARTTLS (perhaps with a valid
certificate). It can then ask the user for upgrading to TLS and automatically
change the configuration setting (STRATTLS). This can also be used in
the 'Never' case (with a don't ask me again checkbox), so that the 'Never'
and the 'Insecure' options will actually become one.
Nelson Bolyard
> I believe that kmail's approach works better (?) in this case w.r.t. the
> end-user. It doesn't alter its behaviour at run-time but it has a 'check what
> server supports' button. This way, the auto-detection is performed once
> (during configuration) and the user is immediately notified.
I like that idea a lot.
Bryan W Clark
There are two major use cases we're looking at w.r.t this problem that
align with what has been discussed.
1) Users w/ TLSiA upgrading from Thunderbird 1,2 to TB3
2) Users creating new accounts in TB3
For (1) I think everyone has agreed that defaulting to STARTTLS as our
lowest level of connection to the server (with the legacy means to
disable STARTTLS in favor of just plain text) means that TB3 can upgrade
to a secure connection as soon as the server supports it and then should
continue to use that secure connection as it's default. This will
transition existing users who are prone to a MITM attack away from that
danger. There are some user interaction issues that need to be worked
out for the upgrade, how to notify the users (if at all) of the upgrade
can be discussed later.
For (2) the new account configuration page (planned to land in TB3b2)
essentially does this 'check what the server supports' automatically for
the user. Servers (POP, IMAP, SMTP) are examined for the type of
connections they support and we default the user to secure protocols
that the server supports. There aren't options for STARTTLS or TLSiA
given to the user, the only option other than secure (SSL or TLS) would
be None. Of course the None option can really be STARTTLS in the same
way (1) works.
So TLS, if available will no longer be in the UI as a choice since we
either upgrade people to TLS or treat them as insecure using STARTTLS.
By being as automatic as we are it will be a win for users to "just get
the right thing" and help move people who were using the "automatic"
secure choice to a real secure choice.
Cheers,
~ Bryan
Ben Bucksch
If you read the thread starting post carefully, that's exactly what
we've already implemented.
--
When responding privately, please remove the ".news" from the email address.
Ben Bucksch
> TB3 can upgrade to a secure connection as soon as the server supports
> it and then should continue to use that secure connection as it's
> upgrade can be discussed later.
You think so? As far as I know, we're past string freeze (but can get an
exception) and nearing feature freeze for TB3, so we need to implement
this ASAP.
> For (2) the new account configuration page
Yeah, that's clear.
There's a third spot, though: The Account Manager. The user can manually
change the settings. What do we do there?
Please see my post <KJOdnUTjkIAPjknV...@mozilla.org> (next
higher up post by me).
Another option would be to just drop ("Use secure connection:") "Never" and
rename "TLS, if available" to "No security". I think that's what you
implicitly suggestioned. That would remove the confusion of having both
"Never" and "No security", but would also remove the option of manually
disabling STARTTLS, e.g. in case a server or proxy misbehaves. I don't
know how common that is, and I have not seen a case yet, so personally,
I'm fine with removing that from the UI (it would still be available as
backend pref via config editor / prefs.js).