Valid vs Invalid SSL certificates - Was: Re: ISPDB configs without STARTTLS and/or SSL
asutherland at asutherland.org
Sun Jan 20 19:59:35 UTC 2013
On 01/20/2013 11:10 AM, Tanstaafl wrote:
> On 2013-01-19 10:49 AM, Andrew Sutherland
> <asutherland at asutherland.org> wrote:
>> A similar, if less strong, case can be made for requiring valid SSL
>> certificates. There are free alternatives like gmail that are known to
>> be, at the very least, competent. And there are free SSL certificates
>> available from StartCom and maybe others.
> I may be misreading this, so would you mind elaborating on what you
> meant above by 'valid SSL certificate'?
My description there was indeed overly terse and used poor terminology
for such a potentially contentious issue.
From the perspective of the Gaia e-mail app there are two main issues:
1) Avoiding man-in-the-middle attacks.
2) Avoiding UX that makes it easy for users to get themselves into a
man-in-the-middle attack situation.
The current Thunderbird/Firefox solution is to use the certificate
authority (CA) system for #1. We accomplish #2 by making it annoying to
add a certificate exception.
As you say, e-mail clients are very different from web browsers. In
reality, the CA system is much worse than SSH's pinned keys in the
steady state since there are many, many CAs that can serve as points of
failure in the system. By default, neither Thunderbird nor the Gaia
e-mail app will complain if your mail server suddenly is using a
certificate issued by a completely different CA.
The thing that CAs have going for them is that since most people aren't
going to carry around a hash of their mail server's key with them, it's
arguably much safer to bootstrap the connection via the CA system. This
is particularly true in the case of the Gaia e-mail app where the
targeted devices are mobile phones which are much more likely to be
relying on un-trustworthy wi-fi networks and cellular networks than
The state of implementation for the Gaia e-mail app and Firefox OS v1 is
that we lack platform/UI support for adding certificate exceptions so it
is simply impossible to create an account when a self-signed certificate
is involved. This is/was a resources/time issue.
It is planned in subsequent revisions of Firefox OS to support adding
certificate exceptions along with the ability to manipulate the set of
trusted CAs, etc. Because those are potentially dangerous operations,
it's unlikely the API for manipulating these things would be exposed to
any web-apps other than (trusted/privileged) settings app(s). For UX
reasons (#2), the settings app is unlikely to support a web activity to
allow other apps to make the process anything approaching
user-friendly. The existence of low-cost and free CA-trusted
certificates helps justify keeping the annoyance level high. For the
e-mail app, we would likely error out about problems with the certificate.
If the ISP database could provide an indicator that the provider is
known to use self-signed certificates (or something similar), it does
seem reasonable to provide a hyperlink to a Mozilla-hosted support page
that explains the problem, trade-offs, and can provide instructions on
how to work around the problem. It would, of course, be even easier and
better if the ISPs could just fix their certificate problems!
It is also my hope to be able to implement some type of certificate
pinning in the Gaia e-mail app by having the mozTCPSocket implementation
either expose information on the certificate in use in such a way that
mozTCPSocket or the e-mail app itself can detect and abort connections
where the certificate has changed. A password-manager mechanism is also
under consideration, and it might turn out that is the better place to
implement the pinning since that will also entail some hookup to the TCP
socket API so that the app can't trick the password-manager into telling
it the secrets.
More information about the tb-planning