On 05/28/2014 07:16 PM, David Keeler wrote:
* there is only a single certificate store on the device and therefore
that all exceptions are device-wide
This is an implementation detail - it would not be difficult to change
exceptions to per-principal-per-app rather than just per-principal.
It's good to know this should be easy, thank you!
* only one exception can exist per domain at a time
In combination with point 3, is this a limitation? Do we want to support
this? If so, again, it wouldn't be that hard.
...
* the exception is per-domain, not per-port, so if we add an exception
for port 993 (imaps), that would also impact https.
I don't think this is the case. Either way, it shouldn't be the case.
In summary, it would not be difficult to ensure that the certificate
exception service operates on a per-principal-per-app basis, which would
allow for what we want, I believe (e.g. exceptions for
{email-app}/example.com:993 would not affect {browser-app}/example.com:443).
I could definitely be wrong; I'm going on discussions with Brian Smith
about 2 years ago and my memory could be quite faulty and/or out-dated.
Taking these two together, I think one exception per domain:port would
be sufficient and possibly even preferable.
My imagined rationale for why someone would use a self-signed
certificate amounts to laziness. (We've been unable to determine what
the rationale is for using invalid certificates in these cases as of
yet.) For example, they install dovecot on Debian/Ubuntu, it generates
a self-signed certificate, they're fine with that. Or they created a
self-signed certificate years ago before they were free and don't want
to update them now. Under this model, it's very unlikely that there's a
server farm of servers each using different self-signed certificates,
which would be the case where we want multiple certificates. (Such a
multi-exception scenario would also not work with my proposed trusted
server thing.)
A theoretical (but probably not in reality) advantage of only storing
one per domain:port is that in the event the key A is compromised and a
new key B is generated, the user would be notified when going back to A
from B.
In terms of solving the issue at hand, we have a great opportunity to
not implement the "press this button to MITM yourself" paradigm that
desktop browsers currently use. The much safer option is to ask the user
for the expected certificate fingerprint. If it matches the certificate
the server provided, then the exception can safely be added. The user
will have to obtain that fingerprint out-of-band over a hopefully secure
channel.
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?" that doesn't presuppose the existence of
DNSSEC/DANE
(http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities)
The problem is that this seems like a very passive aggressive means of
technically addressing the problem without actually enabling the
use-case. User security is primarily increased by making it more likely
the user will physically destroy their phone by throwing it at something
than they will successfully add a certificate exception. Additionally,
only doing the platform work required to enable this means that it's
possible that our partners will just ship a slightly-forked version of
the email app that just automates this process. (Unless we make it so
that there is no way for the email app to automatically determine the
fingerprint so the user really does have to source the certificate from
somewhere else.)
And it's not clear to me how the user would realistically ever receive a
copy of the fingerprint via a secure channel, especially if we're
modeling the use of invalid certificates as down to laziness.
Real-world examples are best, let's take webmail.tcl.com for example.
It provides http/httpS/imap/imapS/ActiveSync over http(s). It uses the
same invalid certificate for all TLS connections. It provides a help
page at http://webmail.tcl.com/help_en.htm and
https://webmail.tcl.com/help_en.htm. It seems like users would likely
be pointed at that help page/similar or stumble upon it themselves while
trying to figure out what to do. If they find the certificate there,
it's obviously not any more secure, it's just more laborious.
NB: I do think that if we must make it possible to insecurely add a
certificate exception, then making it harder for users to do so is
desirable. My original hope was that we'd just provide a mechanism in
the settings app to let users add exceptions and we'd never link the
user directly to this from the email app. Instead we'd bounce them to a
support page first which would require a-hassle-but-not-ridiculous steps
along the lines of the long flow via Thunderbird preferences. It's
unlikely a gmail vanity domain user would decide to actively take all
those steps to compromise their security.
Andrew
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
