Discussion on jitsi ml but it might be relevant for pidgin as well. ---------- Forwarded message ---------- From: Ralf Skyper Kaiser <[email protected]> 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 <[email protected]>
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
_______________________________________________ [email protected] mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
