On 05/28/2014 09:30 PM, Brian Smith wrote:
On Wed, May 28, 2014 at 5:13 PM, Andrew Sutherland
I agree this is a safe approach and the trusted server is a significant
complication in this whole endeavor. But I can think of no other way to
break the symmetry of "am I being attacked or do I just use a poorly
configured mail server?"
It would be pretty simple to build a list of mail servers that are known to
be using valid TLS certificates. You can build that list through port
scanning, in conjunction with the auto-config data you already have. That
list could be preloaded into the mail app and/or dynamically
retrieved/updated. Even if we seeded this list with only the most common
email providers, we'd still be protecting a lot more users than by doing
nothing, since email hosting is heavily consolidated and seems to be
becoming more consolidated over time.
This is a good proposal, thank you. To restate my understanding, I
think the key points of this versus the proposal I've made here or the
variant in the https://bugzil.la/874346#c11 ISPDB proposal are:
* If we don't know the domain should have a valid certificate, let it
have an invalid certificate.
* Preload more of the ISPDB on the device or maybe just an efficient
mechanism for indicating a domain requires a valid certificate.
* Do not provide strong (any?) guarantees about the ISPDB being able to
indicate the current invalid certificate the server is expected to use.
It's not clear what decision you'd advocate in the event we are unable
to make a connection to the ISPDB server. The attacker does end up in
an interesting situation where if we tighten up the autoconfig mechanism
and do not implement subdomain guessing (https://bugzil.la/823640), an
attacker denying access to the ISPDB ends up forcing the user to perform
manual account setup. I'm interested in your thoughts here.
Implementation-wise I understand your suggestion to be leaning more
towards a static implementation, although dynamic mechanisms are
possible. The ISPDB currently intentionally uses static files checked
into svn for implementation simplicity/security, a decision I agree
with. The exception is our MX lookup mechanism at
https://mx.thunderbird.net/dns/mx/mozilla.com
I should note that the current policy for the ISPDB has effectively been
"try and get people to host their own autoconfig entries with an
advocacy angle which includes rejecting submissions." What's you've
suggested here (and I on comment 11) implies a substantiative change to
that. This seems reasonable to me and when I raised the question about
whether such changes would be acceptable to Thunderbird last year,
people generally seemed to either not care or be on board:
https://mail.mozilla.org/pipermail/tb-planning/2013-August/002884.html
https://mail.mozilla.org/pipermail/tb-planning/2013-September/002887.html
https://mail.mozilla.org/pipermail/tb-planning/2013-September/002891.html
I should also note that I think the automation to populate the ISPDB is
still likely to require sizable engineering effort but is likely to have
positive externalities in terms of drastically increasing our autoconfig
coverage and allowing us to reduce the duration of the autoconfig
probing process. For example, we could establish direct mappings for
all dreamhost mail clusters.
Andrew
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
