Valid vs Invalid SSL certificates - Was: Re: ISPDB configs without STARTTLS and/or SSL

Andrew Sutherland asutherland at
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> 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 
desktop/laptop users.

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 mailing list