Hi,
As part of our work to replace Claws Mail with Icedove [1] I have
started to secure the autoconfiguration procedure. In this email I'm
gonna report about my progress and ask for input on a few issues I've
encountered.
[1]
https://tails.boum.org/todo/Return_of_Icedove__63__/
First I'll describe on a high-level what Icedove does during
autoconfiguration, and the security issues. Let's say we enter the
email user@???. Icedove will then, in order, try the following
until something works, otherwise it reports failure:
1. Fetch configuration from disk, i.e. from the Icedove installation.
No security problems here. In fact, we may want to write and ship
our own configuration file for email providers we want to support.
2. Fetch configuration from email service provider. This is done over
HTTP, so it's *not* secure.
3. Fetch configuration from Mozilla's database. Done over HTTPS, so
it's secure as long as we trust Mozilla's database.
4. Fetch configuration from DNS MX record. Without DNSSEC this is also
completely insecure.
5. Guess configuration, e.g. {smtp,imap,pop,pop3}.example.com, and then
try STARTTLS, SSL and plaintext, in that order. The fact that
plaintext is acceptable makes this insecure.
What I've done so far is to introduce an option called
mailnews.auto_config_ssl_only (for brevity I will call it just ssl_only
from now on). It modifies the above in the following way .
1. Fetch configuration from disk: No change.
2. Fetch configuration from email service provider: Disabled when
ssl_only == true.
It would be easy to make it try https first, and then fallback to http
only if ssl_only == false, but a comment in the code makes me unsure if
I want to do so:
> To support domain hosters, we cannot use SSL. That means we
> rely on insecure DNS and http, which means the results may be
> forged when under attack. The same is true for guessConfig(), >though.
Any one that understands the issue?
3. Fetch configuration from Mozilla's database: The database url can be
changed (mailnews.auto_config_url), so when ssl_only == true we only
do this step if the url starts with "
https://".
4. Fetch configuration from DNS MX record: Disabled when ssl_only ==
true.
5. Guess configuration: When ssl_only == true we only probe SSL and
STARTTLS, so the result is never plaintext.
6. I introduced a checkbox called "Only use secure protocols", which is
located right under the "Remember password" checkbox in the account
creation dialog. It directly corresponds/changes the ssl_only value.
Note that a user still can press "Manual configuration" and select
plaintext after SSL/TLS was autoconfigured, or no config was found
(perhaps since the server doesn't offer SSL/TLS).
Issues I'd like input on:
* My question in point 2 above.
* ssl_only really does two separate things:
1. It forces SSL for *fetching* configs.
2. It forces SSL or STARTTLS in the *resulting* configuration when
*guessing* the config.
Is this confusing?
* ssl_only does not check whether any fetched config (like in step 1
and 3) uses plaintext smtp, pop or imap. Do we want this? I wouldn't
ask if it was a trivial change, but this code is a complete mess and
would need a complete reorganization for this feature. It would make
the above point less confusing. But can we live without it?
I guess that's all.
Cheers!
