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

Tanstaafl tanstaafl at
Wed Jan 23 11:41:46 UTC 2013

On 2013-01-20 2:20 PM, ace <acelists at> wrote:
> 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!).

All correct, and no argument from me...

> On the other hand, valid does not mean trusted.

Again, true, and this was one of my points, although I didn't actually 
state it quite so simply... ;)

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

I actually use Cert Patrol but had forgotten about it, so thanks very 
much for reminding me and expanding on this issue. I wholeheartedly 
agree that its functionality should be incorporated into the core code, 
and hadn't considered your point about this functionality (warning about 
CHANGING a cert), and this is a most excellent point - who can argue 
with making something even *more* secure than using signed/trusted 3rd 
party certs?

Thanks again ace!

More information about the tb-planning mailing list