On Thu, May 29, 2014 at 2:03 PM, Andrew Sutherland < asutherl...@asutherland.org> wrote:
> 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. > Right. But, I would make the decision of whether to allow an invalid certificate only at configuration time, instead of every time you connect to the server like Thunderbird does. Though you'd have to solve the problem of dealing with a server that changed from one untrusted certificate to another. > * Preload more of the ISPDB on the device or maybe just an efficient > mechanism for indicating a domain requires a valid certificate. > Right. > * Do not provide strong (any?) guarantees about the ISPDB being able to > indicate the current invalid certificate the server is expected to use. > Right. It would be better for us to spend more effort improving security for secure servers that are trying to do something reasonable, instead of spending time papering over fundamental security problems with the server. > 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. > I think guessing is a bad idea in almost any/every situation because it is easy to guess wrong (and/or get tricked) and really screw up the user's config. Maybe it would be better to crowdsource configuration information much like location services do: get a few users to opt-in to reporting/verifying/voting on a mapping of MX records to server settings so that you can build a big centralized database of configuration data for (basically) every mail server in existence. Then, when users get auto-configured with that crowdsourced data, have them report back on whether the automatic configuration worked. Until we could do that, it seems reasonable to just make sure that ISPDB has the configuration data for the most common commodity email providers in the target markets for FirefoxOS, since FirefoxOS is primarily a consumer-oriented product. > 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: > It seems like you would be able to answer this as part of the scan of the internet, by trying to retrieve the self-hosted autoconfig file if it is available. I suspect you will find that almost nobody is self-hosting it. 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. > Autopopulating all the autoconfig information is a lot of work, I'm sure. But, it should be possible to create good heuristics for deciding whether to accept certs issued by untrusted issuers in an email app. For example, if you don't have the (full) autoconfig data for an MX server, you could try creating an SMTP connection to the server(s) indicated in the MX records and then use STARTTLS to switch to TLS. If you successfully validate the certificate from that SMTP server, then assume that the IMAP/POP/LDAP/etc. servers use valid certificates too, even if you don't know what those servers are. Again, I think if you made sure that GMail, Outlook.com, Yahoo Mail, 163.com, Fastmail, TuffMail, and the major analogs in the B2G markets were all marked "TLS-only-with-valid-certificate" then I think a huge percentage of users would be fully protected from whatever badness allowing cert error overrides would cause. Or, perhaps you could just create a whitelist of servers that are allowed to have cert error overrides, and seed it with only our partners' mail server hostnames and call it a day. Perhaps doing this would allow us to reset the priority of the stuff above to something more reasonable. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
