Autoconfig ISP fetch security review
Ben Bucksch
fetch ISP part of the feature for security review.
I didn't know back then that I had to schedule the meeting myself, so I
waited indefinitely for it to be scheduled. So, I now set the time to
tomorrow, 2009-11-05, 10AM PST = 19:00 CET.
Anybody who wants to see this feature in Thunderbird is welcome to join.
On 2009-01-21, in thread "autoconfig security", I wrote:
We're currently implementing "autoconfig" for Thunderbird, which is
intended to be able to automatically figure out the mail settings needed
to configure an email account, like hostnames, ports, SSL on/off, secure
auth algo etc.. All that the user should need to provide is his real
name, email address and password. We take the domain of the email
address and try to find the configuration from that.
Please see
https://wiki.mozilla.org/Thunderbird:Autoconfiguration#Implementation
I think that's fairly secure (and specifically designed to be). We try
to get the config only by contacting servers at the original domain
example.net (or Mozilla), and that should be under the control of the
mail provider Example Corp. We also try to do that only via secure
mechanisms (which is a pain, because it rules out DNS).
philor, during review, asked for a "formal security review" by the
Mozilla Security Group, so that's what this post is about.
The risk here is that we find and offer a configuration that contains
mail servers operated by an attacker. E.g. Emily wants to set up
em...@example.net, but we find a configuration for example.net that
includes imap.evil.com. Then, evil.com would gain Emily's email
password. Or imap.example.net offers SSL, but the attacker manages to
return a config without SSL nor password encryption, and then using a
MITM to read the cleartext password.
Mitigating factors are:
* There is a small time window for the attacker. It's all only about
the account setup wizard, and setting up an account is a very rare
action, 2 times per year roughly on average.
* The attacker has to run a MITM or DNS attack of some sort.
* We show the configuration (hostnames etc.) to the user before we
create the account, and do not send the password before the user
clicked "Create account".
* The greatest possible danger here is a loss of the email password.
Addons/Extensions or downloads of EXEs pose a *far* far larger
risk. Therefore, we should be careful, but not overly hesitant.
* People currently often use no SSL at all, and instruction pages
instruct entirely unprotected cleartext configs, although SSL is
available. [paragraph added now]
Philor came up with one possibly problematic case: A webhoster which is
allowing customers to register subdomains. So, a customers has
fr...@hoster.com and fred.hoster.com. How, if the attacker registers
autoconfig.hoster.com, it can redirect Fred to imap.evil.com and get the
password.
I can see two possible counter-measures for that:
1) The webhoster must block the autoconfig subdomain or register/use it
himself.
2) We also contact https://www.<domain>/autoconfig/mail/mozilla.xml
/before/ we contact autoconfig.<domain>.
Upside of 2) is that it's a bit easier to set up (no new host). Downside
is that it creates more 404 spam in the hoster's logfile (same as
/favicon.ico, which I hate).
Microsoft has a very, very similar feature in Outlook / Exchange 2007,
which also contacts "https://<domain>/autodiscover/autodiscover.xml" and
"https://autodiscover.<domain>/autodiscover/autoodiscover.xml", so they
do exactly the same (same idea independently), and they used 2) above.
(There are some differences in the XML files, so dropping our own format
in favor of Microsoft's is not a good idea, but I plan to implement the
autodiscover as well, in case we talk to Exchange 2007 servers).
Somebody can see other problematic situations?
Note, however: [slightly modified]
The vast majority of users currently use no SSL and no "secure auth",
because that's too cumbersome to set up without knowing which
combination works, and official instructions are usually incomplete and
outdated. Quite often, the pages instruct to use no SSL and cleartext
passwords.
So, people are already sending their password in the clear, the attacker
just has to sniff it. Given that the risk here is that the passwords
gets discovered, and that requires an *active* attack, I don't think we
can make the situation much worse than it already is.
This feature wants to make the situation much *better*, though, by
configuring SSL for those users where their provider offers it.
Ben Bucksch
> tomorrow, 2009-11-05, 10AM PST = 19:00 CET.
To be clear: That's Thursday, 10AM in California, 18PM in UK and 19:00
in Germany.
http://www.timeanddate.com/worldclock/
> Anybody who wants to see this feature in Thunderbird is welcome to join.
Let's just use the normal TB conference line
<https://wiki.mozilla.org/Thunderbird/StatusMeeting/DialInInfo>
(dmose, do I have to reserve it, have a moderator code or something?)
Ben Bucksch
> Ben Bucksch wrote on 11/4/2009 6:49 AM:
>
>> Microsoft has a very, very similar feature in Outlook / Exchange 2007,
>> which also contacts "https://<domain>/autodiscover/autodiscover.xml" and
>> "https://autodiscover.<domain>/autodiscover/autoodiscover.xml", so they
>> do exactly the same (same idea independently), and they used 2) above.
>> (There are some differences in the XML files, so dropping our own format
>> in favor of Microsoft's is not a good idea, but I plan to implement the
>> autodiscover as well, in case we talk to Exchange 2007 servers).
>>
>
> http://tools.ietf.org/html/draft-nottingham-site-meta
>
Thanks, Bill, for this reference. This is a nice idea.
Ben Bucksch
The security review was a constructive and fruitful discussion. Here are the results:
Central db or ISP fetch has precedence?
I think ISP should have precedence
because I dislike central octopussy authorities,
because they always fire back in the long term.
bwinton preferred MozillaMessaging to control things.
His suggestion was to add a "redirect" element feature to the
config file format. The central database uses this to refer to the
ISP for all domains for which we have no entry (or even for those
for which we have an entry). If we dislike the ISP, we remove
the redirect.
Advantages (central):
- able to change URL (but unlikely once deployed)
- able to override in case it goes wrong for one ISP
Disadvantages:
- central authority, power question
- downtime case
-bug 537649 <https://bugzilla.mozilla.org/show_bug.cgi?id=537649>
- implementation: redirects are recursive and not trivial in combination
with async network fetches.
Still open.
Is SSL critical for config lookup?
DNS MX: Mail delivery between domains happens via DNS MX lookups,
which are insecure. In other words, an attacker can already
re-route and intercept new mails. The risk of interception during
account setup is not larger than that. More importantly:
Guessed configs: An attacker can easily *prevent* connections,
making the ispdb lookup (via https), isp fetch (via https) and
heuristics for IMAP SSL servers and IMAP servers with secure auth mechs
all fail, making us fall back to plaintext auth, and that's it, game over.
Therefore, lookups via http don't add risk.
Domain hosters and SSL
Domain hosters and mail service providers which allow customers to buy their
down domain and use that for email. Example: 1und1.de, fastmail.fm, Dreamhost,
schlund.de etc.
They want to set up an autoconfig server for their customers (incl. customers
with their own domain).
If we require SSL, we'd need to require that the cert domain matches the email
domain, otherwise we'd rely on insecure steps like DNS MX lookups and can just
as well drop the SSL requirement.
However, it's not feasible for a domain hoster to get a cert for each customer
domain.
(Not feasible 1. because of verification processes and costs and 2. because of
the SSL requirement to have one IP address per cert. Neither domain-wildcard
certs nor certs listing several domains are applicable here.)
So, we don't see a way to both support domain hosters and enforce the SSL
requirement (and it being meaningful). Given that we think that domain hosters
are an important case, and attackers can circumvent SSL anyways (see above),
we'll drop SSL and allow http for ISP config looksup. I don't like it at all,
but I don't see an alternative.
(Note that trying SSL first and then falling back to http is snake oil / false
sense of security, because an attacker can always prevent the https-connection,
and there's no sensitive information in the config file either.)
However, dropping the SSL requirement allows us to include other mechanisms
like DNS SRV or MX records which could prove very useful (but not part of this
bug). E.g. if a domain has a DNS SRV entry for _imap, we use that. Or if a MX
for bucksch.com points to mx.fastmail.fm, we could restart config lookup with
fastmail.fm as domain.
References:Bug 342242 <https://bugzilla.mozilla.org/show_bug.cgi?id=342242>,<http://tools.ietf.org/html/draft-daboo-srv-email-02>
re http[s]://autconfig.<domain>/ and philor's concern that somebody at a
subdomain hoster (e.g. dreamhost handing out benbucksch.dreamhost.com to me)
might grab autoconfig.<domain>:
I already argued that we have the same problem with imap.<domain>. philor
responded that imap. is a well-known name and is hopefully blocked for
registration. I think that autoconfig can just as well become such a well-known
block, but philor didn't buy that.
However, Microsoft Outlook does exactly the same, they use
http://autodiscover.<domain>/... . I am not aware of any incidents.
Blake suggested that we use autodiscover.<domain>, given that this should be a
well-known domain for hosters now, too. I think that's a good idea.
(But I still don't think the original problem philor mentioned is real. If a
domain hoster gives out autoconfig.dreamhost.com, that's their problem, and
also easily rectified.)
On 04.11.2009 15:22, Ben Bucksch wrote:
Eddy Nigg
> However, Microsoft Outlook does exactly the same, they use
> http://autodiscover.<domain>/... . I am not aware of any incidents.
Minor correction here, it's https://autodiscover.domain.com/some.xml+stuff
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Ben Bucksch
> Minor correction here, it's
> https://autodiscover.domain.com/some.xml+stuff
>