SSL security concern

[Ralf Skyper Kaiser]

HI Ethan,

thanks for your comments. I've summarized some SSL/TLS Security concerns:

https://thc.org/ssl

and also created a video for those who are non-technical:

http://youtu.be/F3BMA3IuvYs

I made a list of features under section 6.4 that would make pidgin secure.
In summary:

For Jitsi/Pidgin/Jabber this would mean:

   1. Do not allow non-private chats
   2. Do not allow clear-text (non-SSL) connections
   3. Accept self-signed certificates but once accepted/stored do not allow
   certificate to change (even if new certificate is a Verisign signed
   certificate).
   4. Feature to select CAfile storage location
   5. Force client to disable logging
   6. Inform server that user is using lockdown (so that server can reject
   all clients which do not).
   7. Once lockdown option is enabled the user should not be able to change
   any of the above options until lockdown is disabled again (e.g. gray out
   the option). Disconnect when lockdown option changes and reconnect to all
   servers.


The BIGGEST BANG FOR THE BUCK would be 4.: Allow the user to specific a
different (and exclusive) CA location.

It is not a big change and would open up Pigdin to a much larger user base.

regards,

Ralf






On Mon, Oct 14, 2013 at 3:47 PM, Ethan Blanton <elb at pidgin.im> wrote:

> Ralf Skyper Kaiser spake unto us the following wisdom:
> > can you clarify this quote from you please:
> >
> > "That goes against the general philosophy of open source clients. The
> user
> > should be assumed to be responsible."
> >
> > Are you saying that users who use open source clients are assumed to be
> > responsible? (and because of that pidgin should have a lousy SSL security
> > implementation - because the user knows what he is doing)?
>
> Note that David is not a Pidgin developer, and this opinion is his
> own.  It is either a common attitude for Open Source software or a
> common misconception regarding open source software, depending on your
> perspective.  I view it as the latter.  There's no "philosophy" of
> open source that says it has to suck in case the user wants it to.
>
> That said, in this particular instance, we do not have a
> straightforward option for accomplishing what you're asking for, and I
> doubt we will soon provide one.  It is unfortunately quite common for
> users to *need* to accept certificates with untrusted chains,
> mismatched domains, expired signatures, etc.  We do not currently
> provide an option for default disposition (either to confirm or
> reject) of such a situation, we require the user to handle it
> manually.
>
> Ethan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/support/attachments/20131014/05214337/attachment.html>