Valid vs Invalid SSL certificates - Was: Re: ISPDB configs without STARTTLS and/or SSL
tanstaafl at libertytrek.org
Wed Jan 23 11:41:46 UTC 2013
On 2013-01-20 2:20 PM, ace <acelists at atlas.sk> 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
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
Thanks again ace!
More information about the tb-planning