tl;dr: We need to figure out how to safely allow for invalid
certificates to be used in the Firefox OS Gaia email app.  We do want
all users to be able to access their email, but not by compromising the
security of all users.  Read on if you work in the security field / care
about certificates / invalid certificates.


== Invalid Certificates in Email Context

Some mail servers out there use self-signed or otherwise invalid SSL
certificates.  Since dreamhost replaced their custom CA with valid
certificates
(http://www.dreamhoststatus.com/2013/05/09/secure-certificate-changes-coming-for-imap-and-pop-on-homiemail-sub4-and-homiemail-sub5-email-clusters-on-may-14th/)
and StartCom started offering free SSL certificates
(https://www.startssl.com/?app=1), the incidence of invalid certificates
has decreased.  However, there are still servers out there with invalid
certificates.  With deeply regrettable irony, a manufacturer of Firefox
OS devices and one of the companies that certifies Firefox OS devices
both run mail servers with invalid certificates and are our existing
examples of the problem.

The Firefox OS email app requires encrypted connections to servers.
Unencrypted connections are only legal in our unit tests or to
localhost.  This decision was made based on a risk profile of devices
where we assume untrusted/less than 100% secure wi-fi is very probable
and the cellular data infrastructure is only slightly more secure
because there's a higher barrier to entry to setting up a fake cell
tower for active attacks.

In general, other email apps allow both unencrypted connections and
adding certificate exceptions with a friendly/dangerous flow.  I can
speak to Thunderbird as an example.  Historically, Thunderbird and its
predecessors allowed certificate exceptions.  Going into Thunderbird
3.0, Firefox overhauled its exception mechanism and for a short time
Thunderbird's process required significantly greater user intent to add
an exception.  (Preferences, Advanced, Certificates, View Certificates,
Servers, Add Exception.)  At this time DreamHost had invalid
certificates, free certificates were not available, invalid certificates
were fairly common, Thunderbird's autoconfig security model already
assumed a reliable network connection, Thunderbird could only run on
desktops/laptops which were more likely to have a secure network, etc.  
We relented and Thunderbird ended up where it is now.  Thunderbird
immediately displays the "Add Security Exception" UI; the user only
needs to click "Confirm Security Exception".  (Noting that Thunderbird's
autoconfig process is significantly more multi-step.)


== Certificate Exception Mechanisms in Platform / Firefox OS

Currently, the only UI affordance to add certificate exceptions is
exposed by the browser app/subystem for HTTPS sites.  I assert that this
is a different risk profile and we wouldn't want to follow it blindly
and don't actually want to follow it at all[1].

There are general bugs filed on being able to import a new CA or
certificate at https://bugzil.la/769183 and https://bugzil.la/867899.  
Users with adb push access also have the potentially to manually import
certificates from the command line, see
https://groups.google.com/forum/#!msg/mozilla.dev.b2g/B57slgVO3TU/G5TA-PiFI_EJ

It is my understanding that:
* there is only a single certificate store on the device and therefore
that all exceptions are device-wide
* only one exception can exist per domain at a time
* the exception is per-domain, not per-port, so if we add an exception
for port 993 (imaps), that would also impact https.

And it follows from the above points that exceptions added by the email
app/on the behalf of the email app affect and therefore constitute a
risk to all other apps on the device.  This is significant because
creating an email account may result in us wanting to talk to a
different domain than the user's email address because of the
autoconfiguration process and vanity domains, etc.


== The email app situation

In bug https://bugzil.la/874346 the requirement that is coming from
partners is that:
- we need to imminently address the certificate exception problem
- the user needs to be able to add the exception from the account setup
flow.  (As opposed to requiring the user to manually go to the settings
app and add an exception.  At least I think that's the request.)

Taking this as a given, our goal then becomes to allow users to connect
to servers using invalid certificates without compromising the security
of the users who do use servers with valid certificates or of other apps
on the phone.

There are two main problems that we need solutions to address:

1) Helping the user make an informed and safe decision about whether to
add an exception and what exception to add.  I strongly assert that in
order to do this we need to be able to tell the user with some
confidence whether we believe the server actually has an invalid
certificate, whether the user is apparently behind a corporate MITM
proxy, or whether they're under attack.

2) How to add this exception / allow connecting to servers with invalid
certificates in a safe way.  Key goals are to minimize the privileges of
the email app (we would like for it to be privileged, not certified),
and to minimize risk to other apps.  This includes risks from exposing a
dangerous web activity that malicious apps/websites could use.


== Proposed solution for informed, safe decision-making

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.

For example, if the email app contacts sketchy.example.com and finds the
certificate does not validate, I propose that:

*  TCPSocket/XHR with mozSystem return information on the
certificate/chain that we received.

* We contact the trusted server, for example, certchecker.mozilla.org.  
We tell it the domain we tried to contact, the IP, the port, the
protocol, initial-TLS versus startTLS, and the certificate we got back.

* The trusted server attempts to initiate the same connection.
** If a connection occurs, the server checks the certificate it gets
back and returns it to the client as well as a characterization of its
understanding of the situation.  The results would be:
*** "yes, the server has an invalid certificate; the one I got back
matches up exactly with what you told me; let the user choose"
*** "it looks like the certificate would be valid if accessed via a
different domain name, suggest using that domain."  (In theory the
client could make this decision on its own, assuming we expose the legal
alternate names, but the server might be able to know more about this.  
The Thunderbird ISP Database can help answer these questions too, so
this might not be needed.)
*** "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"
*** "unable to connect to the server, try again later"
*** "trusted server is degraded, failing to saying no"
*** "other, say no"

* If and only if the trusted server returns a result and says it looks
like an invalid certificate, prompt the user to see if they want to
allow this connection.

* If we can't talk to the trusted server or for any other reason, we do
not allow the user to add the exception/allow the connection.

Note that the email app will not contact the trusted server if it gets a
valid certificate when it talks to the mail server and that we require
consensus between the local device and the server.  The intent is to
ensure the trusted server cannot be used as a mechanism to attack
devices that are operating on a "safe" network or talking to servers
with valid certificates.

In the worst-case scenario where an attacker both compromises the
device's network and also compromises (or is able to impersonate) the
trusted server we effectively degrade to a yes/no prompt.  An attacker
with this level of sophistication likely already has the ability to
attack the user's own mail server and forge SSL certificates, so this
may be the scenario in the attack tree where we inherently lose.  No
obvious solutions jumps out at me other than maintaining a network of
trusted servers with diverse implementations and operators where our
device requires consensus among multiple servers and uses pinned
connections for these servers.

In terms of making the server somewhat smart / able to provide guidance,
the rationale is that at this time we are effectively unable to update
the email app once it has shipped.  So addressing snafus requires being
able to fix things on the server.

I would propose that we do log the certificates/domains/etc. that we see
for the following reasons:

* Gather information about domains that are using invalid certificates
so that we can evangelize improving their certificate or
autoconfiguration story.  This will also allow us to potentially update
the ISPDB for these servers.

* Gather information about corporate MITM proxies in use so that we can
proactively update our support documentation for users.  This might
imply letting the server have a canned mapping from domains to support
URLs that we could suggest.

* Gain statistics about the number of apparent attacks on our email
userbase.


== Proposed solution for exceptions / allowing connections

There are a variety of options here, but I think one stands above the
others.  I propose that we make TCPSocket and XHR with mozSystem take a
dictionary that characterizes one or more certificates that should be
accepted as valid regardless of CA validation state. Ideally we could
allow pinning via this mechanism (by forbidding all certificates but
those listed), but that is not essential for this use-case.  Just a nice
side-effect that could help provide tighter security guarantees for
those who want it.

The rationale for this:

* In conjunction with the trusted server we are able to ensure that the
key the trusted server sees is the key the device sees is the key we are
adding an exception for.  Just saying "oh yeah, the certificate is
invalid" and then re-fetching the certificate separately where a
different answer could come back is obviously less secure.

* It avoids having any bad decisions made inside the email app
potentially affect other apps or other websites.

* Apps with these permissions are already capable of initiating
unencrypted connections or directly sending information to third
parties, so letting them bypass existing certificate checks is arguably
bad only in that there's one less pressure on server operators to have
valid certificates.

* It avoids needing to give the email app access to a super-dangerous
addCertException API.

* It avoids creating a potentially dangerous web activity.  I have
trouble figuring out how this could be safely done unless the
super-certified app that services the activity is instead the one that
talks to the trusted server.  Otherwise we need to authenticate the web
activity based on its origin, or require that the trusted server
generates a cryptographic attestation about it having seen the invalid
certificate and then have the app validate the attestation.

* Any solution that requires the user to manually verify a fingerprint
for security seems guaranteed to not provide any security.


== Other options?

There are likely to be other options I have not considered or
erroneously discounted.  I realize this is a long email and my points at
https://bugzil.la/874346 are also long, but I would appreciate that any
replies read both to make sure we're all on the same page in terms of
risks to users from the compromise of their email account.  (Do feel
free to skim/skip places where it's clear I'm reiterating discussion
points.)


== Venue

I have picked dev.platform for discussion because I think this is an
important discussion that's relevant to a lot of areas and definitely
has platform implications that concern more than just B2G.  I think it
is of particular interest to those on the dev.security,
dev.security.policy, dev.b2g, dev.gaia, and dev.webapi and so I will be
sending individual pointers to this thread from those groups.

Thanks,
Andrew

1: Specifically, in the web browser case, security does not matter for
every website.  When the user clicks through the exception-adding
process, they are hopefully aware of the context and should be aware of
any active disclosures they make on the website.  For example, they
hopefully know to not do something like enter their bank credentials
after we warned them that they're probably not at their bank website.  
But security arguably matters for all non-throway email accounts.  To
have your email credentials is to be able to read your email,
impersonate you, receive and delete account/password reset emails.  And
compromise of credentials is persistent until they are reset.

Regarding the current certificate exception mechanism:

> * 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.

> * 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).

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 would be wary of implementing a more involved scheme that involves
remote services.

Cheers,
David
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Thanks for the overview of a real problem, Andrew.
(I recall having to add an exception for a "Mozilla Root CA" to
access email at one time.)

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.

> *** "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.

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

Andrew,

Le 29 mai 2014 à 09:13, Andrew Sutherland <asuth...@asutherland.org> a écrit :
> My imagined rationale for why someone would use a self-signed certificate amounts to laziness.

being one of those persons using a self-signed certificate, let's enrich your use cases list ;)
I use a self-signed certificate because the server that I'm managing is used by a handful of persons which are part of community. This community can be friends and/or family. The strong link here is the *human trust* in between people, which is higher than the trust of a third party.


--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

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

On 5/28/2014 5:30 PM, Andrew Sutherland wrote:
> tl;dr: We need to figure out how to safely allow for invalid
> certificates to be used in the Firefox OS Gaia email app. We do want
> all users to be able to access their email, but not by compromising
> the security of all users.  Read on if you work in the security field
> / care about certificates / invalid certificates.

Certificate verification failures, I think, can happen for one of the
following reasons, sorted by rough order that I expect they happen:
* Untrusted CA/self-signed certificate
* Domain name mismatch (e.g., a certificate for foobar.mozilla.org is
used on site foobar.allizom.org)
* Expired certificate
* Insufficiently secure certificate (e.g., certificates that violate
CA/Browser Forum rules or the like. I don't know if we actually consider
this a failure right now, but it's a reasonable distinct failure class IMHO)
* Explicitly revoked
* Malformed certificate

It seems to me that some of these are more tolerable than others. There
is a much different risk profile to accepting a certificate that expired
two days ago versus one that fails an OCSP validation check.

> * the exception is per-domain, not per-port, so if we add an exception
> for port 993 (imaps), that would also impact https.

It's per-host:port. I recently had to add a cert override for an NNTPS
server by hand.

> In bug https://bugzil.la/874346 the requirement that is coming from
> partners is that:
> - we need to imminently address the certificate exception problem
> - the user needs to be able to add the exception from the account
> setup flow.  (As opposed to requiring the user to manually go to the
> settings app and add an exception.  At least I think that's the request.)

I know you and I discussed this in another context not too long ago, and
the common consensus we had agreed then was that doing a non-automatic
manual labor to set up the exception was ideal. Requiring it from the
account setup flow is... slightly disconcerting to me.

> == Proposed solution for informed, safe decision-making

This is a problem I've been thinking about in a slightly different
situation (specifically, for S/MIME certificates). Unfortunately, my
blog post containing these thoughts is still in the process of being
written, so I can't refer you to that post yet.

We have an excellent chance to try to rethink CA infrastructure in this
process beyond the notion of a trusted third-party CA system (which is
already more or less broken, but that's beside the point). My own views
on this matter is that the most effective notion of trust is some sort
of key pinning: using a different key is a better indicator of an attack
than having a valid certificate; under this model the CA system is
largely information about how to trust a key you've never seen before.
There is a minor gloss point here in that there are legitimate reasons
to need to re-key servers (e.g., Heartbleed or the Debian OpenSSL
entropy issue), and I don't personally have the security experience to
be able to suggest a solution here.

I'm not necessarily asking that we immediately find the best solution
right now (particularly given partners' demands for immediacy), but
rather that we think about a solution that can eventually be proposed
for standardization in appropriate standards bodies, and also that we
design a solution that ought to require mostly "technical" fixes as
opposed to architectural redesigns. I know the IETF is currently working
on an extension for key pinning in HTTP that may be relevant here:
<https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/>.

Another relevant fact for the design future is the eventual introduction
of DANE and DNSSEC, which allows the DNS records to indicate the
intended keys of TLS connections. That's not feasible for the near
future, though, especially as I don't think Mozilla has even started
implementing DANE.

>
> 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.

Doesn't the EFF's SSL Observatory already track the SSL certificates to
indicate potential MITMs?

>
> For example, if the email app contacts sketchy.example.com and finds
> the certificate does not validate, I propose that:
>
> *  TCPSocket/XHR with mozSystem return information on the
> certificate/chain that we received.

I think that, in any case, the exact reason for certificate errors [in
terms of the taxonomy I described above] should be returned if
validation fails.

[ I should also point out that I'm planning on asking the WebCrypto
working group about standardizing some certificate stuff--particularly
validation--for S/MIME, since I really, really, really don't want to try
write an OCSP verifier in JS. The discussion of how to identify
certificate details may be relevant for that effort as well. ]

>
> * We contact the trusted server, for example,
> certchecker.mozilla.org.  We tell it the domain we tried to contact,
> the IP, the port, the protocol, initial-TLS versus startTLS, and the
> certificate we got back.

Only over TLS, of course. And if that fails, the user has to execute
$NOT_A_MERE_CLICKTHROUGH steps to fix it.

> * The trusted server attempts to initiate the same connection.

Would it be feasible to ask of partners that they register at least the
fingerprints of their certificates with the trusted server? Then we
could require that the connection's certificate use the same fingerprint
as it has on record, which ought to improve security in the face of
MITMs, excepting issues with firewall MITMs which are really entirely
separate classes of attacks. On the other hand, it would require care in
figuring out how to handle migration of public keys cleanly.

I'd like to imagine that, when DANE support becomes available, we could
assume an untrusted or self-signed certificate is valid if it passes
DNSSEC on the DANE entries.

Alternatively, we could not require pre-registration of fingerprints if
it's already published via DANE. While a do-it-now setup would still
require a trusted server to do the DANE lookups, it would allow for an
eventual retiring of the trusted server middleman and Single Point of
Failure and help prod people to roll out DANE. And maybe even make DANE
more of a priority in Mozilla's codebase? :-)

> == Proposed solution for exceptions / allowing connections
>
> There are a variety of options here, but I think one stands above the
> others.  I propose that we make TCPSocket and XHR with mozSystem take
> a dictionary that characterizes one or more certificates that should
> be accepted as valid regardless of CA validation state. Ideally we
> could allow pinning via this mechanism (by forbidding all certificates
> but those listed), but that is not essential for this use-case.  Just
> a nice side-effect that could help provide tighter security guarantees
> for those who want it.

[ Similar concerns potentially exist for S/MIME, which is mostly the
angle I've thought about this previously. ]

I've preferred to think of the ideal solution as an introduction of a
pinning mechanism, but this needs to take into account revocation and
key upgrades (both gradual, crypto keys-are-now-crackable upgrades and
Heartbleed-level "emergency" key upgrades). I'd propose that your
modifications to TCPSocket et al not have the pinned certificates
override certificates that fail a revocation check.

> * Any solution that requires the user to manually verify a fingerprint
> for security seems guaranteed to not provide any security.

An unusable secure solution ought to be considered an oxymoron:
usability and security are not orthogonal concepts.

> == Other options?
>

I'm not sure where the best place to put these comments are, so here
they go:

1. Any solution should try to only permit the "easy" certificate
override on account configuration. This minimizes scope for potential
MITM attacks.

2. Any solution should also recognize that re-keying of servers is going
to need to happen at some point. I don't know if this point will be
before a "better" long-term solution can be put in place or not.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

On 05/28/2014 08:37 PM, Karl Dubost wrote:
> Le 29 mai 2014 à 09:13, Andrew Sutherland <asuth...@asutherland.org> a écrit :
>> My imagined rationale for why someone would use a self-signed certificate amounts to laziness.
> being one of those persons using a self-signed certificate, let's enrich your use cases list ;)
> I use a self-signed certificate because the server that I'm managing is used by a handful of persons which are part of community. This community can be friends and/or family. The strong link here is the *human trust* in between people, which is higher than the trust of a third party.

Trusting you as a human doesn't translate into protecting the users of
your server from man-in-the-middle attacks.  How do you translate the
human trust into the technical trust infrastructure supported by Firefox
and Thunderbird and the rest of the Internet?

Andrew

Andrew,

Le 29 mai 2014 à 09:50, Andrew Sutherland <asuth...@asutherland.org> a écrit :
> Trusting you as a human doesn't translate into protecting the users of your server from man-in-the-middle attacks.
>  How do you translate the human trust into the technical trust infrastructure supported by Firefox and Thunderbird and the rest of the Internet?

I was replying to the self-signed certificate == laziness.
What I'm saying is that if you have 4 users on your server. You may decide to create a certificate yourself and educate your users about what message the certificate will send to their mail client and teach them why they can accept the warning message in this case.

On 5/28/2014 7:13 PM, Andrew Sutherland wrote:
> 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.)

Two more possible rationales:
1. The administrator is unwilling to pay for an SSL certificate and
unaware of low-cost or free SSL certificate providers.
2. The administrator has philosophical beliefs about CAs, or the CA
trust model in general, and is unwilling to participate in it.
Neglecting the fact that encouraging click-through behavior of users can
only weaken the trust model.

[ Discovered in the course of reading a few CACert root certificate
request bugs. ]
[ Secondary note: most of my thoughts on X.509 certificates are geared
towards its relation to S/MIME, which shares similar but not quite
identical concerns. ]

On 05/28/2014 06:01 PM, Karl Dubost wrote:
> Andrew,
>

> Le 29 mai 2014 � 09:50, Andrew Sutherland <asuth...@asutherland.org> a �crit :

>> Trusting you as a human doesn't translate into protecting the users of your server from man-in-the-middle attacks.
>>  How do you translate the human trust into the technical trust infrastructure supported by Firefox and Thunderbird and the rest of the Internet?
>
> I was replying to the self-signed certificate == laziness.
> What I'm saying is that if you have 4 users on your server. You may decide to create a certificate yourself and educate your users about what message the certificate will send to their mail client and teach them why they can accept the warning message in this case.

But without verifying that the certificate they received is the
certificate you created, those users are open to attack. On desktop we
unfortunately allowed this to become common. We have an opportunity here
to not make the same mistake on mobile.

On Wed, May 28, 2014 at 5:13 PM, Andrew Sutherland <
asuth...@asutherland.org> wrote:

> 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!

IIRC, different apps can share a single HTTPS connection. So, for HTTPS,
you'd also need to modify the HTTP transaction manager so that it doesn't
mix transactions from apps with different cert override settings on the
same connection.

My imagined rationale for why someone would use a self-signed certificate
> amounts to laziness.
>

We encourage websites and mail servers to use invalid and self-signed
certificates by making it easy to override the cert error.

> 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.

This actually happens regularly in real life. If you accumulate all the
cert error overrides for a host then you end up permanently letting every
captive portal the user has accessed the site through MitM the user.

> David Keeler wrote:
>


>  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.
>>
>

David, I would like to agree with you but even I myself have never checked
the fingerprint of a certificate before adding a cert error override for a
site, and I suspect that implementing the solution you propose would be the
equivalent of doing nothing for the vast majority of cases, due to
usability issues.

>  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.

> 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.
>

I don't think that making things difficult for the users of our software is
going to improve things too much because users will blame us for being
harder to use than our competitors.

One way to discourage the use of non-trusted certificates is to have a
persistent UI indication that the certificate is bad in the app, along with
a link to more info so that the user can learn why using such certificates
is a bad idea. This way, even if we make adding cert error overrides easy
for users, we're still putting pressure on the server administrator to use
a valid certificate.

Regarding DANE: Any TLS registry can apply to be a trust anchor in
Mozilla's CA program and we'll add them if they meet our requirements. We
can constrain them to issuing certificates that are trusted only for their
own TLDs; we've done this with some CAs in our program already. Any CA can
give away free certificates to any subset of websites (e.g. any website
within a TLD). Consequently, there really isn't much different about the CA
system we already have and DANE, as far as the trust model or costs are
concerned.

Cheers,
Brian

Le 29 mai 2014 à 10:25, David Keeler <dke...@mozilla.com> a écrit :
> But without verifying that the certificate they received is the
> certificate you created, those users are open to attack.

agreed.
My intent in the discussion is NOT "Let's not verify the certificate is valid"
but to allow the scenario  "This self-signed certificate is from blah and we checked it".

Basically, to have mechanisms where the trust is not a question of centralization.
Centralized trust systems have their own set of weakness and consequences for the infrastructure.

On 2014-05-28, 9:07 PM, Joshua Cranmer 🐧 wrote:
>
> Two more possible rationales:
> 1. The administrator is unwilling to pay for an SSL certificate and
> unaware of low-cost or free SSL certificate providers.
> 2. The administrator has philosophical beliefs about CAs, or the CA
> trust model in general, and is unwilling to participate in it.
> Neglecting the fact that encouraging click-through behavior of users
> can only weaken the trust model.

3. The administrator doesn't actually believe SSL certs protect you from
any real harm, and is generating a cert using the least effort possible
to make a user-facing dialog box go away.

It's become clear in the last few months that the overwhelmingly most
frequent users of MITM attacks are state actors with privileged network
positions either obtaining or coercing keys from CAs, using attacks that
the CA model effectively endorses, using tech you can buy off the shelf.
In that light, it's not super-obvious what SSL certs protect you from
apart from some jackass sniffing the coffeeshop wifi.

- mhoye

On Thursday, May 29, 2014 1:30:20 AM UTC+3, somb...@gmail.com wrote:
> We do want
all users to be able to access their email, but not by compromising the

security of all users. ...

> This decision was made based on a risk profile of ...

So it looks like we know well enough what the best approach should be in general.


> ... With deeply regrettable irony, a manufacturer of Firefox

> OS devices and one of the companies that certifies Firefox OS devices
> both run mail servers with invalid certificates and are our existing
> examples of the problem.
>

> In bug https://bugzil.la/874346 the requirement that is coming from
> partners is that:
> - we need to imminently address the certificate exception problem
> - the user needs to be able to add the exception from the account setup
> flow.  (As opposed to requiring the user to manually go to the settings
> app and add an exception.  At least I think that's the request.)

I'd interpret it as follows: The partners which we cherish say that the current behavior is beyond a red line of theirs. They'd prefer if it never showed any warning, but they're willing to live with it if the warning is part of the flow.


So combining those two, it looks like the highest priority is satisfying the partners, and second priority is to maybe improve the general flow of adding exceptions.

I think it would help to focus on one issue, and for now it seems like that's the partner's issue.

As for solutions, while contacting a trusted server every time there's an exception is an option, it does make the process more complex.

What if there was a trusted server which the app contacted periodically (where the first time happens on first run etc), and download from it a list of :

1. Certificates to trust.
2. Certificates to revoke.

It might be overall simpler to design and implement because it separates the the exception management (periodically with a trusted server) from the sensitive flow when users need to approve of exceptions.

- avih

Seems like we will have to implement some sort allow invalid certs (it makes
me really sad that the system administrators and/or managers of tcl and
telefonica seem
slow to understand the risks of allowing MITM for user credentials).

I like Brian Smith's proposal to add some visual indicator when using
a non-secure connection and I also agree that making users type the
fingerprint (on a mobile device) is also a non-solution.
I propose making the user type something like:

'I understand that my password to use $mailprovider cannot be protected by
firefoxOS'

And then allow the 'one click' override. (ditto for non SSL connections).

Also in all these variations we have not discussed what should happen
if the untrusted cert changes, my guess is that we should show some delta
of the two certs (once we have detected we are not behind a captive portal)

Camilo

On 5/28/14, 4:16 PM, David Keeler wrote:
> Regarding the current certificate exception mechanism:
>

>> * 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.
>

>> * 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).
>

> 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 would be wary of implementing a more involved scheme that involves
> remote services.
>
> Cheers,
> David
>

> On 05/28/2014 03:30 PM, Andrew Sutherland wrote:
>> tl;dr: We need to figure out how to safely allow for invalid

>> certificates to be used in the Firefox OS Gaia email app.  We do want

>> all users to be able to access their email, but not by compromising the

>> security of all users.  Read on if you work in the security field / care
>> about certificates / invalid certificates.
>>
>>

>> == Invalid Certificates in Email Context
>>
>> Some mail servers out there use self-signed or otherwise invalid SSL
>> certificates.  Since dreamhost replaced their custom CA with valid
>> certificates
>> (http://www.dreamhoststatus.com/2013/05/09/secure-certificate-changes-coming-for-imap-and-pop-on-homiemail-sub4-and-homiemail-sub5-email-clusters-on-may-14th/)
>> and StartCom started offering free SSL certificates
>> (https://www.startssl.com/?app=1), the incidence of invalid certificates
>> has decreased.  However, there are still servers out there with invalid

>> certificates.  With deeply regrettable irony, a manufacturer of Firefox

>> OS devices and one of the companies that certifies Firefox OS devices
>> both run mail servers with invalid certificates and are our existing
>> examples of the problem.
>>

>> * there is only a single certificate store on the device and therefore
>> that all exceptions are device-wide

>> * only one exception can exist per domain at a time

>> * the exception is per-domain, not per-port, so if we add an exception
>> for port 993 (imaps), that would also impact https.
>>

>> And it follows from the above points that exceptions added by the email
>> app/on the behalf of the email app affect and therefore constitute a
>> risk to all other apps on the device.  This is significant because
>> creating an email account may result in us wanting to talk to a
>> different domain than the user's email address because of the
>> autoconfiguration process and vanity domains, etc.
>>
>>
>> == The email app situation
>>

>> In bug https://bugzil.la/874346 the requirement that is coming from
>> partners is that:
>> - we need to imminently address the certificate exception problem
>> - the user needs to be able to add the exception from the account setup
>> flow.  (As opposed to requiring the user to manually go to the settings
>> app and add an exception.  At least I think that's the request.)
>>

>> Taking this as a given, our goal then becomes to allow users to connect
>> to servers using invalid certificates without compromising the security
>> of the users who do use servers with valid certificates or of other apps
>> on the phone.
>>
>> There are two main problems that we need solutions to address:
>>
>> 1) Helping the user make an informed and safe decision about whether to
>> add an exception and what exception to add.  I strongly assert that in
>> order to do this we need to be able to tell the user with some
>> confidence whether we believe the server actually has an invalid
>> certificate, whether the user is apparently behind a corporate MITM
>> proxy, or whether they're under attack.
>>
>> 2) How to add this exception / allow connecting to servers with invalid
>> certificates in a safe way.  Key goals are to minimize the privileges of
>> the email app (we would like for it to be privileged, not certified),
>> and to minimize risk to other apps.  This includes risks from exposing a
>> dangerous web activity that malicious apps/websites could use.
>>
>>

>> == Proposed solution for informed, safe decision-making
>>

>> 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.
>>

>> For example, if the email app contacts sketchy.example.com and finds the
>> certificate does not validate, I propose that:
>>
>> *  TCPSocket/XHR with mozSystem return information on the
>> certificate/chain that we received.
>>

>> * We contact the trusted server, for example, certchecker.mozilla.org.
>> We tell it the domain we tried to contact, the IP, the port, the
>> protocol, initial-TLS versus startTLS, and the certificate we got back.
>>

>> * The trusted server attempts to initiate the same connection.

>> ** If a connection occurs, the server checks the certificate it gets
>> back and returns it to the client as well as a characterization of its
>> understanding of the situation.  The results would be:
>> *** "yes, the server has an invalid certificate; the one I got back
>> matches up exactly with what you told me; let the user choose"
>> *** "it looks like the certificate would be valid if accessed via a
>> different domain name, suggest using that domain."  (In theory the
>> client could make this decision on its own, assuming we expose the legal
>> alternate names, but the server might be able to know more about this.
>> The Thunderbird ISP Database can help answer these questions too, so
>> this might not be needed.)

>> *** "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"

>> == Proposed solution for exceptions / allowing connections
>>
>> There are a variety of options here, but I think one stands above the
>> others.  I propose that we make TCPSocket and XHR with mozSystem take a
>> dictionary that characterizes one or more certificates that should be
>> accepted as valid regardless of CA validation state. Ideally we could
>> allow pinning via this mechanism (by forbidding all certificates but
>> those listed), but that is not essential for this use-case.  Just a nice
>> side-effect that could help provide tighter security guarantees for
>> those who want it.
>>

>> The rationale for this:
>>
>> * In conjunction with the trusted server we are able to ensure that the
>> key the trusted server sees is the key the device sees is the key we are
>> adding an exception for.  Just saying "oh yeah, the certificate is
>> invalid" and then re-fetching the certificate separately where a
>> different answer could come back is obviously less secure.
>>
>> * It avoids having any bad decisions made inside the email app
>> potentially affect other apps or other websites.
>>
>> * Apps with these permissions are already capable of initiating
>> unencrypted connections or directly sending information to third
>> parties, so letting them bypass existing certificate checks is arguably
>> bad only in that there's one less pressure on server operators to have
>> valid certificates.
>>
>> * It avoids needing to give the email app access to a super-dangerous
>> addCertException API.
>>
>> * It avoids creating a potentially dangerous web activity.  I have
>> trouble figuring out how this could be safely done unless the
>> super-certified app that services the activity is instead the one that
>> talks to the trusted server.  Otherwise we need to authenticate the web
>> activity based on its origin, or require that the trusted server
>> generates a cryptographic attestation about it having seen the invalid
>> certificate and then have the app validate the attestation.
>>

>> * Any solution that requires the user to manually verify a fingerprint
>> for security seems guaranteed to not provide any security.
>>
>>

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

On Thu, May 29, 2014 at 2:03 PM, Andrew Sutherland <
asuth...@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

On 05/29/2014 07:12 PM, Brian Smith wrote:
> On Thu, May 29, 2014 at 2:03 PM, Andrew Sutherland <
> asuth...@asutherland.org> wrote:
>
> 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 agree with your premise that the number of people self-hosting
autoconfig entries is so low as to not be a concern other than not
breaking them and allowing that to be an override mechanism for the ISPDB.

Also, https://scans.io/ has a number of useful internet scans we can use
already, so I don't think we need to do the scan ourselves for our first
round.  While the port 993/995 scans at https://scans.io/study/sonar.cio
are somewhat out-of-date (2013-03-30), the DNS dumps and port 443 scans
are modern and should be sufficient to achieve a fairly comprehensive
database. Especially if we make the simplifying assumption that all
relevant mail servers have been operational at the same domain name
since at least then.  (Obviously the IP addresses may have changed so
we'll need to use a reverse DNS dump from the appropriate time period.)

> 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.

Very interesting idea on this!  Thanks!

Andrew

On 05/28/2014 06:30 PM, Andrew Sutherland wrote:
> == Proposed solution for exceptions / allowing connections
>
> There are a variety of options here, but I think one stands above the
> others.  I propose that we make TCPSocket and XHR with mozSystem take
> a dictionary that characterizes one or more certificates that should
> be accepted as valid regardless of CA validation state. Ideally we
> could allow pinning via this mechanism (by forbidding all certificates
> but those listed), but that is not essential for this use-case.  Just
> a nice side-effect that could help provide tighter security guarantees
> for those who want it.

Note: I've sent an email to the W3C sysapps list (the group
standardizing http://www.w3.org/2012/sysapps/tcp-udp-sockets/) about
this.  It can be found in the archive at
http://lists.w3.org/Archives/Public/public-sysapps/2014May/0033.html

Andrew

On 29/05/14 07:01, Mike Hoye wrote:
> It's become clear in the last few months that the overwhelmingly most
> frequent users of MITM attacks are state actors with privileged network
> positions either obtaining or coercing keys from CAs,

I don't think that's clear at all. Citation needed.

I think it's more likely that they are intercepting SSL using crypto or
implementation vulnerabilities without explicit CA cooperation.

> using attacks that
> the CA model effectively endorses, using tech you can buy off the shelf.
> In that light, it's not super-obvious what SSL certs protect you from
> apart from some jackass sniffing the coffeeshop wifi.

Even if you are right, the answer is still "everyone apart from the US
government".

Gerv

On 28/05/14 17:49, Joshua Cranmer 🐧 wrote:
> * Insufficiently secure certificate (e.g., certificates that violate
> CA/Browser Forum rules or the like. I don't know if we actually consider
> this a failure right now, but it's a reasonable distinct failure class
> IMHO)

We would refuse e.g. a cert with an MD5 signature. In the future, we
hope to refuse certs of insufficient bitlength.

> It seems to me that some of these are more tolerable than others. There
> is a much different risk profile to accepting a certificate that expired
> two days ago versus one that fails an OCSP validation check.

Actually, no. Because as soon as a certificate expires, the CA has no
obligation to keep revocation information available for that cert. So
the two are actually equivalent.

That is to say, if a cert is expired, then you may not receive an OCSP
response for it. And you can't make any assumptions about what that
response might have been - it might have been "revoked".

> We have an excellent chance to try to rethink CA infrastructure in this
> process beyond the notion of a trusted third-party CA system (which is
> already more or less broken, but that's beside the point). My own views
> on this matter is that the most effective notion of trust is some sort
> of key pinning: using a different key is a better indicator of an attack
> than having a valid certificate; under this model the CA system is
> largely information about how to trust a key you've never seen before.
> There is a minor gloss point here in that there are legitimate reasons
> to need to re-key servers (e.g., Heartbleed or the Debian OpenSSL
> entropy issue), and I don't personally have the security experience to
> be able to suggest a solution here.

Forgive me, but that sounds like "I'm going to propose a solution with
one glaring flaw that has always sunk it in the past, and then gloss
over that flaw by saying 'I don't have the security experience - someone
else fix it'."

> Doesn't the EFF's SSL Observatory already track the SSL certificates to
> indicate potential MITMs?

The SSL Observatory's available data is a one-off dump from several
years ago. They are collecting more data as they go along, but it's not
public.

> 1. Any solution should try to only permit the "easy" certificate
> override on account configuration. This minimizes scope for potential
> MITM attacks.

That sounds like a reasonable idea, actually; by analogy with Bluetooth
pairing.

Gerv

On 5/30/2014 12:00 PM, Gervase Markham wrote:
> On 28/05/14 17:49, Joshua Cranmer 🐧 wrote:
>> We have an excellent chance to try to rethink CA infrastructure in this
>> process beyond the notion of a trusted third-party CA system (which is
>> already more or less broken, but that's beside the point). My own views
>> on this matter is that the most effective notion of trust is some sort
>> of key pinning: using a different key is a better indicator of an attack
>> than having a valid certificate; under this model the CA system is
>> largely information about how to trust a key you've never seen before.
>> There is a minor gloss point here in that there are legitimate reasons
>> to need to re-key servers (e.g., Heartbleed or the Debian OpenSSL
>> entropy issue), and I don't personally have the security experience to
>> be able to suggest a solution here.
> Forgive me, but that sounds like "I'm going to propose a solution with
> one glaring flaw that has always sunk it in the past, and then gloss
> over that flaw by saying 'I don't have the security experience - someone
> else fix it'."

Actually, that is essentially what I'm saying. I know other people at
Mozilla have good security backgrounds and can discuss the issue, and I
was hoping that they could weigh in with suggestions on this thread. I
acknowledge that the re-keying is a difficult issue, but I also don't
have the time to do the research myself on this topic, since I'm way
backed up on a myriad of other obligations.

>> Doesn't the EFF's SSL Observatory already track the SSL certificates to
>> indicate potential MITMs?
> The SSL Observatory's available data is a one-off dump from several
> years ago. They are collecting more data as they go along, but it's not
> public.

The EFF does things that aren't public?! :)

More seriously, are they actively attempting to detect potential MITMs,
and would they announce if they did detect one? Andrew had in his
proposal a note that reporting of fingerprints could be used to detect
MITMs, and I was implying that this was duplicating work others were
already doing.

On 2014-05-30 12:53 PM, Gervase Markham wrote:
> On 29/05/14 07:01, Mike Hoye wrote:
>> It's become clear in the last few months that the overwhelmingly most
>> frequent users of MITM attacks are state actors with privileged network
>> positions either obtaining or coercing keys from CAs,
>
> I don't think that's clear at all. Citation needed.
>
> I think it's more likely that they are intercepting SSL using crypto or
> implementation vulnerabilities without explicit CA cooperation.

A colleague of mine at CMU just published a paper on exactly this
question: https://www.linshunghuang.com/papers/mitm.pdf

One-sentence summary: the most frequent sources of MITM attacks on HTTPS
connections *specifically to Facebook* are (a) locally installed
malware, (b) institutional transparent proxies for virus scanning,
Internet "filtering", and so on.

Nothing was detected that was obviously, or even plausibly, an attack by
a state surveillance agency, although (if they do do this) one would
hope they are at least competent enough to not make it obvious.

----

Reading through the whole discussion, it sounds to me like TOFU +
pinning (this exact cert chain is trusted only for this specific host)
would be a reasonable short-term solution for existing email servers
with self-signed certificates.  I don't have any better ideas for the
long term, but maybe we should reach out to the owncloud, Mailpile, etc.
developers and talk to them about what *they* see as an ideal solution.
  (Mailpile especially has people on staff who care deeply about UX.)

zw

On 30/05/14 18:53, Joshua Cranmer 🐧 wrote:
>> Forgive me, but that sounds like "I'm going to propose a solution with
>> one glaring flaw that has always sunk it in the past, and then gloss
>> over that flaw by saying 'I don't have the security experience - someone
>> else fix it'."
>
> Actually, that is essentially what I'm saying. I know other people at
> Mozilla have good security backgrounds and can discuss the issue, and I
> was hoping that they could weigh in with suggestions on this thread. I
> acknowledge that the re-keying is a difficult issue, but I also don't
> have the time to do the research myself on this topic, since I'm way
> backed up on a myriad of other obligations.

https://www.youtube.com/watch?v=BKorP55Aqvg&feature=youtu.be

:-)

> The EFF does things that aren't public?! :)

It would appear so. There are many reasons why this might be - privacy,
lack of time to publish, etc. I haven't asked them.

> More seriously, are they actively attempting to detect potential MITMs,
> and would they announce if they did detect one?

I don't know, and presumably yes :-)

Gerv