Thunderbird:Autoconfiguration:Security review FetchConfigFromISP

Template

Overview

We’re currently (mid‐2009) implementing mechanisms within Thunderbird that automatically configure user accounts. All that the user should need to provide is a name, an email address and a password. Given those data, Thunderbird will seek the configuration parameters. Ideally, the provider of the user’s email service would publish the configuration parameters. This document reviews the security of the protocol that governs Thunderbird’s attempts to retrieve configuration parameters from the provider of the user’s email service.

The original discussion of mechanisms within Thunderbird that automatically configure user accounts occurred in 2008-03. A security review of mechanisms within Thunderbird that automatically configure user accounts began in 2009-01.

Security and Privacy

Details are scattered amidst the remainder of this document. It is, apparently, the responsibility of the reader to identify those details as such.

Exported APIs

1. [An attempt to retrieve a rendition of https://{domain_from_email_address}/mail/mozilla.xml?emailaddress={email_address} (the resource that has an identifier that is the concatenation of “https://”, the domain from the email address, “/mail/mozilla.xml?emailaddress=” and the email address).]
2. An attempt to retrieve a rendition of https://autoconfig.{domain_from_email_address}/mail/mozilla.xml?emailaddress={email_address} (the resource that has an identifier that is the concatenation of “https://autoconfig.”, the domain from the email address, “/mail/mozilla.xml?emailaddress=” and the email address).

Thunderbird expects that the response to a successful attempt to retrieve a rendition have an entity and that the entity have an Internet media type (erroneously “MIME type”, “MIME-type”, “mimetype”) of either “text/xml” or “application/xml” and that the entity have a body and that the body of the entity conform to the file format designed for expressing configuration parameters for user accounts in Thunderbird.

Module interactions

• XmlHttpRequest
• E4X

Data

1. Input: a document that conforms to the file format designed for expressing configuration parameters for user accounts in Thunderbird.
2. Output: internal AccountConfig data structure (a JavaScript object).
3. Final result: configuration of a mail account.

Reliability

• Error UI: If Thunderbird is unsuccessful in its attempts to retrieve explicit configuration parameters from the provider of the user’s email service, Thunderbird will proceed silently to other sources of configuration parameters. There is no user interface (in some conventional sense) to signal an error to the user.
• User confirmation: If Thunderbird is successful in its attempts to retrieve explicit configuration parameters from the provider of the user’s email service, Thunderbird will present those parameters to the user. Thunderbird will concurrently provide an affordance (like a button with the label “Create Account”) so that the user may express approval of the parameters, which approval will initiate Thunderbird’s storage of the parameters for future use.

Configuration

• The email address that the user enters is a basis for constructing one or two URLs. The other parts are fixed, as defined above.
• Currently (mid‐2009), there’s no mechanism to configure Thunderbird to skip the attempts to retrieve configuration parameters from the provider of the user’s email service. The user can, however, reject the parameters that Thunderbird presents. After such rejection, the user may enter configuration parameters at will.

Relationships to other projects

The authors do not know of any relationships between this project and other projects.

Security considerations

• A goal of the move toward automatic configuration of accounts is to move users from insecure email service to email service over encrypted channels (as with SSL and TLS) and to email service that employs secure mechanisms of authentication.
• A risk is that Thunderbird find and offer parameters that specify the use of an attacker’s servers.
  • Example: A user wants to configure an account with the email address example@example.net, Thunderbird finds operable parameters for example.net, the parameters specify the use of mailbox host mail.evil.example (a host under the control of an attacker), and the attacker obtains the user’s password.
  • Example: A user wants to configure an account with the email address example@example.net, mail.example.net (a host under the control of the provider of the user’s email service) offers service over encrypted channels, an attacker manages to provide configuration parameters to Thunderbird, the parameters specify the use of mailbox host mail.example.net, the parameters specify the use of unencrypted channels, the parameters specify the passage of unencrypted passwords, the attacker employs man‐in‐the‐middle techniques to spy on the user, and the attacker obtains the user’s password.
• To retrieve configuration parameters, Thunderbird will use HTTP on a transport of SSL or on a transport of TLS. Thunderbird will abort the retrieval if the server presents an improper certificate. We chose this protocol over DNS, our choice being more secure than DNS is.

Mitigating factors

• Thunderbird presents configuration parameters to the user for the user’s review and approval.
• Most users today (mid‐2009) use unencrypted channels and send unencrypted passwords. Secure email service is too cumbersome to arrange when the user doesn’t know which combination works. Official instructions are usually incomplete or outdated or both. The result is that users are already sending passwords in the clear, leaving the attacker with the relatively easy task of sniffing those passwords. If the attacker feeds malicious configuration parameters to Thunderbird and Thunderbird uses those parameters (our worst case), the attacker leaves fairly obvious traces and runs a very high risk of detection. In contrast with passive sniffing, this active transgression presents a high bar.
• The risk exists only in the moment when the user creates the account, not during daily (or, likely, more frequent) authentication.
• Add‐ons, extensions and inscrutable, executable code pose a far greater risk than do the mechanisms under review.

Review comments

Philor

Philor: A service provider allows customers to register subdomains. The service provider assigns email addresses to customers such that the email addresses of each customer correspond directly to the subdomains of that customer. So, a customer who has registered the domain name fred.example.net receives the email address fred@example.net. If the attacker registers the domain name autoconfig.example.net, how can the attacker direct another customer to mail.evil.example and get the password?

Ben Bucksch: I see two counter‐measures:

1. The service provider blocks the “autoconfig” subdomain or registers and uses the “autoconfig” subdomain.
2. Thunderbird could try https://{domain_from_email_address}/autoconfig/mail/mozilla.xml?email={email_address} before trying https://autoconfig.{domain_from_email_address}/autoconfig/mail/mozilla.xml?email={email_address}

The advantage of the latter is the ease of setting up (no new domain name). The disadvantage of the latter is manifest in the logs of the service provider, where one finds a mess of entries for responses in which the status code was “404” (as with “favicon.ico”, which I hate).

Microsoft has a feature in Outlook 2007 that is very similar to the feature under review. The Microsoft products try https://{domain_from_email_address}/autodiscover/autodiscover.xml and https://autodiscover.{domain_from_email_address}/autodiscover/autodiscover.xml in that order. (Differences between Microsoft’s “autodiscover.xml” documents and our “mozilla.xml” documents indicate that dropping our own format in favor of Microsoft’s is not a good idea, but I plan to add an implementation of the protocol that Outlook 2007 implements, in case we talk to Exchange 2007 servers.)

Also, we require a proper SSL certificate. I think that many of these service providers withhold exclusive use of IP addresses, the typical scenario being shared, virtual hosting, which prevents the use of a proper SSL certificate. I think that certificate authorities demand that the recipient of a certificate control the second‐level domain, not just a subdomain, but I’m not sure about that.