On 05/28/2014 07:22 PM, Karl Tomlinson wrote:
(I recall having to add an exception for a "Mozilla Root CA" to
access email at one time.)
It's fairly common that there exist multiple aliases to access a mail
server but the server does not have certificates available for all of
them. In the specific Mozilla case, this was probably
https://bugzil.la/815771.
Andrew Sutherland writes:
I propose that we use a certificate-observatory-style mechanism to
corroborate any invalid certificates by attempting the connection
from 1 or more trusted servers whose identity can be authenticated
using the existing CA infrastructure.
Although this can identify a MITM between the mail client and the
internet, I assume it won't identify one between the mail server
and the internet.
I understand your meaning to be that we won't detect if the mail
server's outbound SMTP connections to other domains and inbound SMTP
connections from other SMTP servers either support, strongly request, or
require use of TLS (likely via STARTTLS upgrade).
I confirm the above and that the issue is somewhat orthogonal. This is
something we would probably want to do as in-app advocacy via
extension/opt-in either by scraping transmission headers or downloading
a prepared database and cross-checking.
*** "it looks like you are behind a corporate firewall that MITMs
you, you should add the firewall's CA to your device. Send the
user to a support page to help walk them through these steps if
that seems right."
*** "it looks like the user is under attack"
I wonder how to distinguish these two situations and whether they
really should be distinguished.
What I imagined here was that the certificate would identify itself as
allegedly originating from the given vendor. We could treat that as a
sufficient hint using RegExps, or analyze the entire chain to cover
cases where the vendor uses their own trust root that we can add to a
small database. In the very bad cases where all of the vendor's devices
use the same certificate, that's also easy to identify.
I think it's a meaningful distinction to make since we are able to tell
the user "You should be able to talk privately with the mail server, but
the network you are using won't let you and wants to hear everything you
say. Your options are to use a different network or configure your
device to use the proxy. For example, you might want to use cellular
data rather than wi-fi or pick a different wi-fi network, like a guest
network."
I'm not sure it's a must-have-on-first-landing feature, especially since
I don't think Firefox OS devices are particularly enterprise friendly
right now. For example, in order to actually authenticate MoCo's
non-guest wi-fi you need to be able to import the certificate (or add an
exception! :) which are what two of those bugs I linked to are about.
But I'd want to make sure we could evolve towards supporting that
direction better.
Andrew
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
