A Public Statement Regarding Ubiquitous Encryption on the XMPP Network | Hacker News Reader

A Public Statement Regarding Ubiquitous Encryption on the XMPP Network

github.com

34 pointsfenollp11 comments

A simple comment to share Jitsi[1]. It uses XMPP but also many other protocols. It encrypt text/audio/video and even have a share and control screen feature.

I discovered it Friday. Our team will certainly use it as a secure replacement for Hangouts and Skype. My only complain is that it doesn't use my already existing gpg keys.

[1]: https://jitsi.org

The pidgin client/libpurple library is notably unrepresented.

Yeah, the list seems impressive until you assemble a list of non-signatories.

I'm not sure libpurple needs to be modified. This all sounds like things application developers can already accomplish by using it right.

an Adium developer is listed and Adium is libpurple-based, isn't it? That kind of implies these changes will have to occur to libpurple, even if it's just on a fork.

I always use a .onion xmpp server. Moxie has a review of gibberbot somewhere on his blog and all its TLS failings

Looks like they disabled their faulty alternative trust manager, and are back to using the built in one:

https://github.com/guardianproject/ChatSecureAndroid/blob/50...

While I respect the effort, this doesn't really do much about thwarting the NSA, assuming that's a big part of the reason for this. The suspicion is that they have the master keys anyway and can decrypt SSL/TLS at will.

For the PKI/CA part, yes (kind of.) There, the NSA can command a CA based in the U.S. to issue them an intermediary CA cert which would allow them to do active MITM for nearly all servers in the world. (They would still need the individual service providers' private keys to do passive MITM and decrypt already-captured traffic, though.)

With just self-signed certificates, the NSA would need an individual's private key. The problem here is that there's no third party to confirm that public key X really belongs to your friend Jane and not the NSA, and thus it's hard to confirm that you're actually speaking directly to Jane, and not to Jane through the NSA. This is a hard problem, and one of the most effective workarounds we have is the support in OTR (typically used over XMPP) for the socialist millionaire protocol, which is a way for two people to confirm that they both know some low-entropy secret that they exchanged over an outside channel/in person, e.g. "batman", without revealing what the secret actually is. If the protocol fails, you can just break the connection.

(Yes, I know that all of this assumes that the client software is written right, and that the NSA hasn't broken e.g. AES-GCM or chacha20poly1305 in TLS 1.2. As of right it doesn't look that way.)

(I'm also acutely aware that our hypothetical attack model doesn't factor in all of the NSA's other tricks, but that's a very deep rabbit hole.)

Some clients use certificate pinning of known popular XMPP hosts. For example, ChatSecure (née GibberBot) on Android appears to use Moxie's certificate pinning for cert chains of a few well-known Jabber servers (like Google and Facebook's), so you will get a warning if they ever start presenting you with new certificates from a different CA.

The implementation leaves a little to be desired; the way it's implemented, any of the CAs for any of the pinned organizations could issue certs that could MITM you, but that's still a lot less than the usual default list of CAs in the system trust store.

> appears to use Moxie's certificate pinning for cert chains

Marlinspike and Perrin actually proposed TACK ( http://tack.io/draft.html ) which requires changes to TLS.

Certificate pinning is different ( simpler and less flexible ) and does not require protocol changes, the logic is held at the application level.

Reply on news.ycombinator.com