Potential expansion of ISPDB scope for Gaia Email app invalid/self-signed certificate issues

Andrew Sutherland asutherland at asutherland.org
Sun Jun 1 07:36:52 UTC 2014


In order to deal with the issue of invalid certificates for the Firefox 
OS Gaia email app (which *requires* encrypted connections), we need to 
consider expanding the scope of the ISPDB.  For detailed context, please 
see https://bugzil.la/874346 and the dev.platform thread "B2G, email, 
and SSL/TLS certificate exceptions for invalid certificates" also 
available at 
https://groups.google.com/forum/#!topic/mozilla.dev.platform/lT4Mhi-B1JI

The headline changes that I think fall out from the current discussion 
and/or should be done while we're putting the effort into this:

- The ISPDB becomes not only a source for a configuration data, but also 
a source for knowing whether we expect a server to have a valid 
certificate or not.  If the ISPDB (or derived data stored locally on the 
device) says the server has a legit certificate, we don't let the user 
add an exception.  If the ISPDB says the server has a bad certificate, 
we allow it.  If the server isn't in the ISPDB, we allow it.

- Therefore we try and list *every* mail server in there.  As listed in 
the thread, there are some useful internet scans at https://scans.io/ 
that can help us out with this.  This is a notable change since there 
are cases where we have refused the addition of smaller entries to the 
ISPDB and instead encouraged the hosting of an autoconfig file somewhere.

- We would precompute/roll DNS SRV lookups, DNS MX lookups, DNS 
forward/reverse lookups based on name guessing (which addresses the 
dreamhost multiple mail cluster situation), domain guessing via 
certificate alternate name inspection, etc. into this.  This would 
obviate the need for Thunderbird's sub-domain guessing or a second 
dynamic MX lookup pass.  Automatically added entries would be tagged to 
indicate they were automatically generated and to indicate what 
heuristics fired to cause them to be the way they are.

- Since we won't actually have credentials to test against these 
servers, we may need to convey to the email app that we're not sure how 
the username should be formatted and that probing should try 
"user at domain" first and then follow up with "user" if that somehow 
fails.  This may be problematic for Thunderbird and may require a schema 
rev from 1.1 to 1.2.

- We might eventually end up with an opt-in "report these settings to 
Mozilla to help other people configure their mail-server" that gets 
reported to the ISPDB in the event someone does manual config. This 
would be to help us learn about errors in the ISPDB and to help us 
discover additional domains that need coverage.  Since this is 
potentially an attack vector this information wouldn't do anything 
automatic and would be checked by scripting and human eyes.  (No 
credentials would be sent; just simple pattern matching to check whether 
the username seemed to include the full domain/etc./etc.)

- The current strategy of a static ISP database that is reviewed by 
humans and maintained in source control would be kept.  However 
automated tooling would be used to prepare some huge checkins that would 
largely just be skimmed.  These would be broken into separate risk-level 
commits based on which heuristics fired/whether the mailserver domain is 
different than the MX domain to help make it easier for humans to review 
these now or in the future.

The Gaia email app's autoconfig behaviour would also change somewhat.  
While we would still allow ISPs to override the ISPDB by hosting an 
autoconfig file at one of two locations, these requests would only be 
made against https:// servers and would be made in parallel with the 
ISPDB request as well as our ActiveSync AutoDiscover probes.  A valid 
ISPDB result for a server may hasten any timeouts against the parallel 
requests to avoid problems we've seen with blackholed 
autoconfig/autodiscover attempts.  A hint in ISPDB that we should wait 
around for the autoconfig server might be something we eventually do if 
slow servers turn out to be a problem.

Thoughts and feedback welcome and appreciated.  Note that the Gaia email 
app wanting these changes need not change the ISPDB Thunderbird uses if 
Thunderbird doesn't want them; Gaia email can use a different 
domain/revision control/etc./etc.

Andrew



More information about the tb-planning mailing list