Re: Autoconfig ISP fetch security review

[Eran Hammer-Lahav]

On Nov 5, 8:58 pm, Bil Corry  wrote:
> Gervase Markham wrote on 11/5/2009 2:00 AM:
>
> > On 05/11/09 04:58, Bil Corry wrote:
> >> You may want to consider registering a /.well-known/ path for this,
> >> which it seems perfectly suited for:
>
> >>        http://tools.ietf.org/html/draft-nottingham-site-meta
>
> > That draft seems like a "let's make the best of it" way of dealing with
> > an unfortunate inevitability :-|.
>
> For anyone who has suggestions or recommendations to improve it, it's being 
> discussed on IETF apps-discuss:
>
>        https://www.ietf.org/mailman/listinfo/apps-discuss
>
> - Bil

You might also want to take a look at the related host-meta proposal
[1] as well as the WebFinger project. Host-meta provides a well-known
location document for protocols with simple metadata or policy
requirements and WebFinger defines a way to find profile and
configuration information about accounts (which in the case of email
providers is also about email addresses).

EHL

[1] http://tools.ietf.org/html/draft-hammer-hostmeta
[2] http://code.google.com/p/webfinger/
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Re: Autoconfig ISP fetch security review

[Bil Corry]

Gervase Markham wrote on 11/5/2009 2:00 AM: 
> On 05/11/09 04:58, Bil Corry wrote:
>> You may want to consider registering a /.well-known/ path for this,
>> which it seems perfectly suited for:
>>
>>  http://tools.ietf.org/html/draft-nottingham-site-meta
> 
> That draft seems like a "let's make the best of it" way of dealing with
> an unfortunate inevitability :-|.

For anyone who has suggestions or recommendations to improve it, it's being 
discussed on IETF apps-discuss:

https://www.ietf.org/mailman/listinfo/apps-discuss


- Bil

___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Re: Autoconfig ISP fetch security review

[Ian G]

On 04/11/2009 15:49, Ben Bucksch wrote:

As requested during the review of autoconfig, I would like to pose the
fetch ISP part of the feature for security review.



On the whole, I would say that it should be Mozilla's working practice 
to aggressively promote this sort of work.  We need improvements in 
security and usability, and they won't be coming on a silver platter 
from elsewhere;  if you can do this, by all means.


I read the rest of the post, and where I saw/understood the security 
weaknesses presented, these seemed to be acceptable risks of attacks 
that would occur in the fullness of time, by which time you can better 
refine and develop the proposals.  E.g., acknowledge, accept, mitigate 
later.


my 2c.

iang
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Autoconfig ISP fetch security review

[Ben Bucksch]

As requested during the review of autoconfig, I would like to pose the 
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. That's Thursday, 10AM in 
California, 6PM in UK and 19:00 in Germany.

http://www.timeanddate.com/worldclock/

Anybody interested in security is welcome to join. Let's just use the 
normal TB conference line



F-up-To: mozilla.dev.apps.thunderbird . See there for updates.


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 
f...@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./autoconfig/mail/mozilla.xml 
/before/ we contact autoconfig..
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:///autodiscover/autodiscover.xml" and 
"https://autodiscover./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.

___
dev-security mailing list
dev-