Tor Messenger Beta: Chat Over Tor, Easily | Hacker News Reader

Tor Messenger Beta: Chat Over Tor, Easily

blog.torproject.org

184 pointsrendx41 comments

If the setup screen stays the way it is, this is probably never going to take off. The fact that it's officially coming from Tor devs is important and I'm sure people who already use Tor can use this app relatively easily, but if the point is to get more people to use secure and private messaging apps, asking people to enter their xmpp credentials isn't the way to go. Additionally, adding GTalk, Facebook Chat etc. into the mix is only going to confuse people because they'll assume they're secure just by using this app. But in order to have a secure and private conversation you need people on both ends of the conversation to use a client that supports OTR.

They mentioned Pond and Ricochet in that post and I'm a big fan of both but especially Ricochet. It has no setup, no configuration. Just share your address and talk. That's the way it should be. But it's only available on desktops. These days most people connect to the internet only by using their smartphones and if you only support desktop computers (even if you're x-platform) you're missing out on a lot of people already. The perfect solution would be Signal's encryption combined with Telegram's availability, but unfortunately we're not there yet.

I'll keep my eye on this project and I really do hope it takes off but as of right now, it's not that different from any other secure messaging app you can find on the internet that only tech savvy people can use.

As soon as Signal has native clients for OS X, Windows, and Linux, it's game over. I will use Signal exclusively for chatting everywhere.

What is the deal with the year+ it has taken to get this done? I'm sure that the WhatsApp thing took a large amount of effort, but that was over 6+ months ago, right? Is Twitter demanding too much of the Whisper Systems folks' time on other projects?

I believe Moxie left Twitter back in 2013.

So it seems! Thanks for the info.

I am a huge fan of signal but it will never be the end game. Society needs communications that hide both content AND metadata. Signal only really hides content.

The only programs I am aware of that do both all have significant limitations in other areas and none have gone through rigorous peer review.

i2p-bote has mobile and desktop applications, can use possible post quantum secure encryption, it's asynchronous and real time, capable of multi party communication, and has optional delays between hops making it global passive adversary secure. Unfortunately it doesn't work well because many messages don't actually make it through. You can't send files greater than 500kb. Also it is not peer reviewed.

Bitmessage has multiparty communication and is asynchronous but has a terrible user interface, is hard to setup, no mobile application, no attachments, no peer review.

Ricochet works well and is easy to use but no attachments, it can't be asynchronous, no multiparty communication, and no peer review.

Haven't played with pond. It looks promising.

My wish list for the ultimate messenger: easy to use, secure by default, hides content and metadata, is multi party, can share arbitrarily large files, is both instantaneous and asynchronous, can be global passive adversary secure, is quantum computer secure, truly multi platform, and supports being signed in on multiple devices at once.

I'm sorry to derail the conversation with my lack of technical understanding but how do we protect metadata?

If we have two devices (say Alice's phone and Bob's phone) that are sending messages to each other, how do we make sure nobody knows who is talking to whom? The answer seems non-trivial to me.

Could we use Alice's and Bob's public keys to encrypt the message and then send them to the entire network, relying on the security of the encryption (and acknowledging that a third part can read all messages any way)? Is there a way to look at a public key and an encrypted message and say that yes, this message was encrypted with this key? It seems that we'd be paying through the nose in terms of throughput capacity (and processing capacity as everyone would have to take in everyone else's packets) if we wanted to maintain metadata privacy this way. I'm sure this is not what you had in mind. Can you please elaborate on how we can secure metadata?

That's essentially how BitMessage works, although with an added proof-of-work functionality to reduce spam.

I don't think the protocols are that similar. Bitmessage is a "eveyone gets every message sent by anyone" type of situation. Bote is a mixnetwork with a dht cache. Ricochet is also built on a mix network but with out a dht cache. Pond uses servers.

https://pond.imperialviolet.org

May I suggest taking a look at https://ricochet.im/ for exactly this.

Ricochet is great :) Very easy to use. Unfortunately, it will be very difficult if not impossible to make it support group chat.

Bitmessage hides the metadata by sending a given message from one person to another person to everyone in the network (it obviously has scaling problems!). Because everyone gets every message you can't really see the metadata.

I2p-bote routes the messages through multiple intermediaries with layered encryption so that no intermediary knows both the ultimate sender or ultimate recipient.

Pond works by running servers over tor (a mixnet). When you send a message it doesn't go to the server you have service through it goes directly to the recipients server.

Ricochet sets up your own server on tor that you are hosting.

There is also Pir-Tor. It attempts anonymity by using the secure multiparty communication combined with PIR to attain provable anonymity.

> ... how do we protect metadata?

By using traffic obfuscating systems like TOR or Mixmaster.

That's my hope as well, but do they even plan on doing that? I know they're working on bringing TextSecure to Chrome as an extension, but that seems to be it.

I also agree with khed. Signal needs to hide metadata.

Hmm, what I was thinking of as the in-progress desktop client is just a Chrome extension: https://github.com/WhisperSystems/TextSecure-Browser. I hope there's more to come. :\

Eh. That's not so bad. From my very limited experience, it seems that the extension would put you 90% of the way to a working Node.js program, which you could then slap behind any frontend you cared to create.

A very brief perusal of the repo didn't turn up any protocol docs, but seem to have been rather thorough about that sort of thing in the past, so I would suspect that the changes to the TS and RedPhone protocol would be fully documented, so you could integrate it with libpurple or whatever.

> But in order to have a secure and private conversation you need people on both ends of the conversation to use a client that supports OTR.

Tor Messenger doesn't allow you to talk with someone else, unless they have OTR. So it's encryption always, by default.

I agree with the mobile part though. We need something that works on both the places. Check out http://conversations.im/omemo/.

For the curious, this is InstantBird (which uses Pidgin's libpurple* library for chat and Mozilla for UI/rendering) plus the Off The Record/OTR plugin (for encryption of content) plus a Tor client.

Note that InstandBird last had a release in December 2013 and their blog was abandoned in July 2014, so their future is a bit up in the air even though commits still happen on the Mercurial repository at Mozilla. Pidgin has released multiple security updates since the December 2013 release of InstantBird 1.5. I'm unsure if the Tor folks have incorporated these changes offhand. They use the clunky gitweb client for web browsing of their repository and I don't have time to clone a git repo at the moment.

It's also worth noting that Pidgin's libpurple uses XMPP for Facebook and Google chats, neither of which will work well any longer due to both of them deprecating XMPP.

If you'd like to use secure chat and are unconcerned with the meta-data, there are quite a few better options at present. If you'd like to use secure chat over Tor, you can use any of those options over the Tor network manually. This does have a lot of promise for making it easier for a regular end user, though, so testing and feedback are encouraged.

*Update - According to a comment reference below, they now build without libpurple using their own custom Javascript libraries.

Instantbird still seems to be under very active development. See the comm-central repository, which is Instantbird.

Tor Messenger does not seem to be using libpurple, at least judging by the comments here: https://lwn.net/Articles/662471/#Comments. And I tried it with Google Talk and it works. Wikipedia says that Google Talk as a client was deprecated but you can still use it with third-party clients like Pidgin, Tor Messenger, etc.

That's surprising. Thanks for the link. So, they rewrote all of libpurple's chat handling in Javascript?

You can still mostly connect into Google via XMPP, it's just a bit clunky. And it doesn't work as a true XMPP service as you can't connect to anyone but Google with it. I'm using it in Pidgin right now.

Could you point me to those options? I haven't been able to find something that works for me.

I'm not sure if this is what you meant, but putting the OTR plugin in the middle of a list of pre-existing software makes it look like they used one. There wasn't one and they had to write a new one for InstantBird wrapping libotr:

https://github.com/arlolra/ctypes-otr

Wow, I had no idea the Tor Project was working on something like this. There really hasn't been a good solution for secure, multi-platform instant messaging. My contacts are fragmented across different services, most of which do not have (let alone enforce) clients with end-to-end encryption. I'm really hoping for some sort of platform that can gain widespread adoption and that isn't restricted to any particular device or OS.

What is described in the post won't force end-to-end encryption. It is more or less the same as using your current IM client over Tor: you still depend on a server which you may not control and communication between this server and your contact (directly or via your contact's server) may not be encrypted all the way. To be secure you would still need to use OTR, even if your contact also uses a Tor enabled IM client.

Otherwise if you want end-to-end over Tor communication, Ricochet works quite well :).

Yes, I understand that, but AFAIK the only halfway decent client on OS X that supports OTR is Adium, and the UX is really bad. A simpler, more reliable client with OTR is welcomed. The direct integration with the Tor network is the icing on the cake.

The UX is not the biggest issue, but rather the buggy library it is based on. There is an alternative: https://jitsi.org/

tox.im is more what you want I'd say. The DHT means its super easy to use for custom notification solutions IMO.

So far I've tried connecting to Google Talk, Twitter, and Facebook. Google Talk and Facebook both blocked the connection and sent me notices that they thought my account had been compromised. After confirming with Facebook that it really was me, the next login succeeded. Google Talk continued to block additional connection attempts even after I logged in on the web and marked the blocked attempt as really being me. I've previously had trouble with this issue with Gmail when I was attempting to use a Gmail address for notifications sent from Monit on a cloud server. While you can tell Google that a connection attempt in the past was really you, this doesn't seem to have any effect on the next login attempt, so effectively Tor Messenger doesn't work with Google for me.

In general, the fact that each time you launch the client (or generate a new path through the Tor network) you get a new IP, these sorts of security measures put in place by the chat networks could be a difficult issue to work around.

The biggest problem with connecting to Google Talk and Facebook is that they have deprecated XMPP access[1]. Well Google hasn't really, but they might as well have[2].

As someone who trains people on using XMPP and OTR, Google Talk used to be a great XMPP service and now makes it very difficult for most users to understand why they are having problems with the service.

1) https://developers.facebook.com/docs/chat 2) https://xmpp.org/2015/03/no-its-not-the-end-of-xmpp-for-goog...

So this is compatible with XMPP? I've been toying the idea of setting up an xmpp server and this may push me over the edge...

Yes it is. I have Tor Messenger running without problems with two different XMPP servers.

Great to see this - there was a similar project I tried awhile ago (https://github.com/prof7bit/TorChat) and it was quite disappointing to see it no longer maintained.

Good to have another E2EE chat option. End to end encryption needs to be the new normal. It's not enough to just encrypt the connection to your service anymore. That might have been a feather in the caps of eCommerce sites in the 90s, but today we can and should do better.

I agree, it's nice to have a choice in end-to-end messaging services. But now that iMessage/Signal/TextSecure exist, seems like end-to-end messaging is solved. People need to move on to harder end-to-end use cases that go beyond OTR messaging.

I guess Tor will provide more anonymity, which is a nice plus.

It crashes for me right on start (Unhandled exception at 0x0EDC9BD5 (d2d1.dll) in instantbird.exe: 0xC0000005: Access violation writing location 0x00000000.). But once fixed, it can be great.

You can try the following workaround: https://trac.torproject.org/projects/tor/ticket/17453#commen...

Interesting, I never heard of instantbird before. This is great news!

Also https://news.ycombinator.com/item?id=10474591.

Avira alerts me that it found some kind of malware in instantbird.exe.

What name does your AV return for the malware warning when running instantbird.exe?

Reply on news.ycombinator.com