On Thu, May 28, 2015, at 12:31 PM, Christiane Ruetten wrote:
> On 28/05/2015 17:46, Andrew Sutherland wrote:
> > While there are mitigations (discussed on the bug), in general it seems
> > preferable to concentrate engineering efforts on making it easier to
> > obtain and configure valid certificates (a la Let's Encrypt), or to help
> > users switch to email providers who take security/privacy remotely
> > seriously.
>
> I would strongly object to this line of argument. In terms of SSL, the
> perhaps most serious way of doing e-mail is via a small, privately-run
> server with a self-signed CA that's pinned in the client.
>
> Helping users who consciously choose such an e-mail setup over to a less
> secure or less privacy-assuring solution – which unfortunately includes
> Let's Encrypt – does not seem like the right signal to send.
>
> So I would not only call for engineering effort for proper certificate
> management through the settings (I agree that ad-hoc prompting is
> somewhat dangerous), but also for configurable pinning of CAs to certain
> servers, and for alerting the user whenever that CA spontaneously
> changes on the server side.
I think we may actually be in agreement and I was too terse, leading you
to think I was saying something I was not. My statement was
specifically referring to mitigations discussed on the bug for the
"ad-hoc" prompting scenario. The ambiguity when we receive an invalid
certificate is whether:
1) The server just has a self-signed / otherwise invalid certificate.
2) The user is under attack.
A specific mitigation would be to have the Thunderbird ISPDB/a web
service either statically or dynamically indicate: "Yeah, I'm seeing the
same invalid certificate for that domain too" or "oh yeah, this server
has been showing this invalid certificate for a long time, so I guess
it's okay". The same mechanism would also need to be used if the
apparent certificate used by the server changed. Allocating engineering
effort to this end is basically creating a second ad-hoc trust
infrastructure.
CA and/or certificate pinning seems quite reasonable and indeed will
provided additional security and confidence, but is a separate issue
from prompting to add exceptions.
I do think it's reasonable to say that if a user wants to add a
certificate exception, pinned CA, or pinned certificate, that it should
be done explicitly through the settings UI. It need not be arduous, but
it's still not appropriate to do the prompting scenario because of the
ambiguity of the "Hey, this is either an attacker or your actual mail
server" situation, and that for most users any dialog is going to be
viewed as a "Hey, do you want your mail or not?" that they're just going
to click through.
Andrew