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 <e...@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 >
_______________________________________________ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support