Thunderbird:Autoconfiguration:Security Review

Overview

This feature makes it much easier to configure new mail accounts by looking up the configuration based on the e-mail address, and if that fails, doing port probing based on host names derived from the e-mail address. We are not considering the isp config file fetching in this review section

Background links

Security and Privacy

This feature is not a security feature.
What potential security issues in your feature have you already considered and addressed?
If the pref that controls the url we fetch config files is compromised, we could fetch evil config files and send the user's password to an attacker. But this is true of other existing prefs that control host names.
As above, if an attacker manages to insinuate themselves into the config file fetching process, they can get access to the user's e-mail address and password. But this doesn't seem any different from a standard web mail app.
During host probing (which is only done if we could not find a config file for the e-mail domain), given an e-mail address "user@foo.com", we will probe things like mail.foo.com, pop3.foo.com, imap.foo.com and if we find a mail server, we will present the host name to the user and will send the password to the host when the user clicks Finish. This makes us somewhat vulnerable to the sub-domain issue described here - https://wiki.mozilla.org/Thunderbird:Autoconfiguration:Security_review_FetchConfigFromISP#Philor - except that the attacker would register the sub-domains mail.foo.com,imap.foo.com, etc.

Exported APIs

Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)

 This feature adds a new method to nsIMsgIncomingServer and nsISmtpServer called verifyLogon, that validates the user name and password.

Does it interoperate with a web service? How will it do so?
Explain the significant file formats, names, syntax, and semantics.
Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
Does it change any existing interfaces?

Module interactions

log4moz.js, https, general mailnews backend code.

Data

XML files defining server settings for a given e-mail address domain are retrieved from a mozilla messaging directory, and parsed. The fields in the file are range checked.
This feature outputs incoming and outgoing (SMTP) server configurations.
These are stored as prefs, like all server configurations in Thunderbird.

Reliability

We warn the user if the connection to the server is not secure (i.e., not SSL or TLS). We also warn the user about certificate errors (e.g., self-signed certs) but we allow the user to override the errors.
We temporarily create server objects to validate logon - if we crash during that process, the prefs for those server objects will remain in prefs.js. We also add temporary cert overrides when doing SSL port probing, and it would be up to the cert manager to clear those overrides in the case of a crash.
Autoconfig will use SSL or TLS connections when possible, so overall it gives the users much more security than the in-secure connections that the existing wizard forces you to create. For common domains, the canned config files should mostly prevent accidental configuration errors, which are a security issue in their own right.
We display the host names and ports we will connect to, and we won't send passwords without an explicit click from the user to create the account.

Configuration

The end user can not configure the settings, other than changing the config file url via about:config.
There are no build options or #ifdefs for developers. This feature is almost entirely js and xul.
What ranges for the tunable are appropriate? How are they determined?
What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

Relationships to other projects

This feature is not related to any other projects, though the isp config file fetching potentially is related to a similar Microsoft project.