Fwd: The real security threat are rogue CAs.
Discussion on jitsi ml but it might be relevant for pidgin as well. -- Forwarded message -- From: Ralf Skyper Kaiser sky...@thc.org Date: Fri, Nov 22, 2013 at 11:09 AM Subject: It's not about random vs. urandom. The real security threat are rogue CAs. To: Jitsi Developers d...@jitsi.org Hi, thanks for the discussion about which random source (/dev/random or /dev/urandom) to use. The discussion was helpful and enlightening. It is good to discuss this. As with many things a balance has to be found between what security feature gives you the biggest bang for the time spend implementing it. In the absence of any academic or practical attack to compromise a DH or DSA key generated from a /dev/urandom source we shall assume that the Jitsi communication is secure for the foreseeable future. How your jitsi communication is compromised right now is the way how TLS certificates are handled. (All XMPP clients suffer from the same problem and Jitsi is not an exception). There is a lot we learned from the Snowden files and what happened since 2007. Example with Jitsi using TLS: Etisalat, a major telecommunication operator in the United Arab Emirates, has the power to generate a valid X.509 certificate for jabber.google.com without google knowing about it. All XMPP clients currently accept this 'rogue' certificate. Etisalat can intercept the TLS connection to jabber.google.com without any warning shown by the XMPP client. The reason for this is that Jitsi verifies the jabber.google.com TLS X.509 certificate against any of the installed Certification Authorities (CA). I mention Etisalat here because we know from the Etisalat-Blackberry incident from 2007 that Etisalat is a trusted Certification Authority (e.g. their ROOT Ca key is shipped with windows) and has abused its power by signing a Blackberry/RIM firmware update and infecting 143.000 of blackberry customers with surveillance software. The XMPP client is trusting a bad player. (If you are currently transiting via Dubai Airport you might want to turn of Jitsi). But this is not about Etisalat. The SSL Observatory project estimates that there are currently around 800+ different 'companies' in 52+ different countries with different econimical and geopolitical interrest that can generate a rogue certificate for jabber.google.com. Anyone of those has the power to generate a rogue certificate for any XMPP-server in the world. All of those have the 'trust' anchored with a CA that is installed and comes with our OS. Anyone of those has the (techincal) ability to intercept the TLS connection without Jitsi showing a warning to the user. We know from the various leaks (snowden and wikileaks spyfiles) that TLS Proxies have been purchased by governments with a rather questionable track record of Human Rights abuses and a lack of respect for private communication. We know that government sponsored pervasive Internet surveillance happened during the 2011 revolutions all around the world. We know that citizens got arrested, tortured or worse for wrongly assuming that their Internet communication was secure. XMPP was no exception. If you ever want to save somebody's life then fixing this problem is your best shot. Fixing this problem gives you the biggest security improvement for the time spend developing it. Certificate Pinning solves this problem. https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 Certificate Pinning is in the last stages of becoming an RFC. It's not there yet but chrome and other browser manufactures have already implemented it. It would require a protocol change in the XMPP protocol (the server would have to offer two certificates: an actual certificate and a backup certificate). There is an intermediate solution which works without protocol changes: Certificate Pinning Light The client cut 'pin' a server certificate to a host-name the same way that ssh clients 'pin' the host key to a host-name (known_hosts). There is a lot of activity on making the s2s XMPP connections secure. More about this at https://github.com/stpeter/manifesto. It's a great step by mostly those who operate the XMPP backend network. The c2s XMPP connection is the last leg where security can make a real difference. regards, ralf ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
TLS Everywhere, jabber
FYI,.. sounds good. move into the right direction to make pervasive surveillance harder and protect jabber/XMPP communication. - Original Message Subject: [jdev] TLS Everywhere Date: Sun, 27 Oct 2013 21:23:08 -0600 From: Peter Saint-Andre stpe...@stpeter.im Reply-To: Jabber/XMPP software development list j...@jabber.org To: j...@jabber.org Almost 15 years have passed since my friend Jeremie Miller released the initial version of the jabberd IM server, launching the Jabber open-source community and the technology we know today as XMPP. Yet, all that time, hop-by-hop encryption using SSL/TLS has been optional on the XMPP network. A number of server operators and software developers in the XMPP community have decided that needs to change for the better. Based on discussions at the XMPP Summit last week in Portland, Oregon, I have drafted a plan for upgrading the XMPP network to always-on, mandatory, ubiquitous encryption. You can find it here: https://github.com/stpeter/manifesto In short: we owe it to those who use XMPP technologies to improve the security of the network (and thanks to Thijs Alkemade, we now have better ways to test such security, using the newly-launched IM Observatory at xmpp.net). Although we know that channel encryption is not the complete answer, it's the right thing to do because it will help to protect people's communications from prying eyes. If you or your organization develop XMPP-compatible software or run a service that's connected to the XMPP network, I encourage you to sign the statement by following the instructions in the README at the URL shown above. Thanks! Peter ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: SSL security concern
David, 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)? regards, skyper On Sun, Sep 22, 2013 at 11:39 PM, David Woolley for...@david-woolley.me.ukwrote: On 22/09/13 21:26, skyper wrote: 1. Which ROOT CA storage does pidgin use to authenticate a server side SSL certificate? See ./configure --help. At a quick scan, it looks like it uses its own set of root certificates by default. The default will depend on the OS, at least to some extent. On Debian, it looks like the default is /usr/share/purple/ca-certs. If you didn't compile it yourself, the choices made by the packager may differ from the build system defaults. 2. How can I configure pidgin to use one (and just one; exclusive) ROOT CA storage (or single certificate) and ignore all other system-wide root certs without having to recompile the source? On that reading. If it has been compiled to use its own certificates, delete the other certificates. Again, on the above reading, this will be a global change for all libpurple clients. If it has been compiled to use a system directory, your caveat cannot be met. 3. How can I harden pidgin to fail connecting to the jabber server if SSL trust can not be established? I do not want to see any warning that the SSL cert can not be authenticated or the user being asked if he trusts the certificate manually. That goes against the general philosophy of open source clients, that the user should be assumed to be responsible. My guess is that this not only requires recompiling, but also requires source code changes. Please note I'm not an expert on this. I'm just going on a very quick scan of the configure script, and the general design philosophy of open source client software. __**_ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/**mailman/listinfo/supporthttp://pidgin.im/cgi-bin/mailman/listinfo/support ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: SSL security concern
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
Re: SSL security concern
Hi, So ... we already implement a large portion of this list, either explicitly or implicitly. To wit: For Jitsi/Pidgin/Jabber this would mean: 1. Do not allow non-private chats I don't know what this means. ...if OTR plugin is available then do not allow non-encrypted private messages. 4. Feature to select CAfile storage location This is already provided, as a compile-time option. This is not feasible to the average user. (point taken, developers know how to use pidgin securely. everyone else should go to hell?) 5. Force client to disable logging This is not an option, but can easily be achieved by marking ~/.purple/logs unwriteable by the user. Option should be available cross-platform and without OS specific hacks. 6. Inform server that user is using lockdown (so that server can reject all clients which do not). This is not useful, as a client can readily lie. This is not the point. The client can also circumvent your no-logging idea by putting up a camera and filming his screen. The point is that it takes reasonable effort and prevents _accidental_ client misconfiguration. 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. I don't see what this buys. We're unlikely to implement it. Prevents accidental misconfiguration by the user. A server rule could create a rule to only let clients connect that are in lockdown. This would ensure against these accidental misconfigurations: 1. User has logging disabled 2. User is authenticating against server supplied/server-trusted cert (and not one of the 600+ CA's out there) 3. User can not send unencrypted private messages etcetcetc. It prevents accidental client misconfiguration which form the majority of all security problems. This is a disingenuous and misplaced statement. I assume you're trying to bribe egos. However, a) Pidgin is already used by many millions of users, b) the much larger user base is a small fraction of those millions consisting of (for example) certain financial companies, a small number of privacy-concerned tech-savvy individuals, etc. I think there is a use case for such a feature. There is currently no easy to use and secure IM client on the market. History (last 2-3 years, and recent PRISM leaks) have shown that governments (and I'm not just talking about the US here) are intercepting SSL traffic on a massive scale (see the DigiNotar-Iran incident, The Blackberry-Etisalar incident, the PRISM case, ...etc etc etc). This has been made possible because of lax security implementation - not just in pidgin but across the board. Firefox and Chrome are now on the forefront for implementing stricter SSL security (including certificate pinning, HSTS and exclusive CA locations). David: Saying that this is not required reminds me of a discussion in the 80s when the car manufactures said that Airbags are not required (That cars have a break and that people should drive responsibly. Only a small ruthless-driving group of people would benefit.). regards, Ralf ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: SSL security concern
Brian, yes, correct. and It's a good feature to have. Yet we see users sending unencrypted messages even when they think they are using OTR with private message encryption (yes, users are sometimes stupid). An option that use encryption by default (which can be disabled by the user) provides better security at no cost to usability. So why not do it? regards, Ralf On Mon, Oct 14, 2013 at 7:54 PM, Brian Morrison b...@fenrir.org.uk wrote: On Mon, 14 Oct 2013 19:25:21 +0100 Ralf Skyper Kaiser wrote: 1. Do not allow non-private chats I don't know what this means. ...if OTR plugin is available then do not allow non-encrypted private messages. This can be set on a per-contact basis for those who use OTR. -- Brian Morrison ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
