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

ace acelists at
Sun Jan 20 19:20:17 UTC 2013


For some people email may be much more important than financial
transactions. E.g. somebody may be OK if somebody snoops out that he
bought tickets to a concert (that 1000s of other people have done too)
using some throw away debit card where the balance on the associated
account is always 0 (he tops it up just before any transaction). But
somebody may want to much more protect what secret/private info he sent
to his co-worker/agent/family member. But yes, you can do encryption (of
your choosing) of messages in this case (which the communication with
financial institution does not allow you to!).

On the other hand, valid does not mean trusted. As long as the client
(FF/TB) does NOT warn you that the server replaced one valid cert
(signed by authority) with another (the current bad state). There is the
Certificate patrol extension for now, but this warning must be moved to
the core product. So in this case self-signed certs may actually be
better, as the client will warn you about the change (the exception does
not cover the new cert).


-------- Original Message --------
Subject: Valid vs Invalid SSL certificates - Was: Re: ISPDB configs
without STARTTLS and/or SSL
From: Tanstaafl <tanstaafl at>
To: tb-planning at
Date: Sun, 20 Jan 2013 11:10:27 -0500

> 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.
> Hi Andrew,
> I may be misreading this, so would you mind elaborating on what you
> meant above by 'valid SSL certificate'?
> It sounds like you mean 'signed by a trusted 3rd party'.
> First and foremost, I hope you will agree that there is a big difference
> between SSL certificate usage in a web browser and in an email client.
> Web browsers are used for (among other things) financial transactions.
> Email clients are not. Every single legitimate argument I have ever seen
> discusses this issue only from the standpoint of the web browser and
> financial transactions.

More information about the tb-planning mailing list