Main menu

Tor Messenger Beta: Chat over Tor, Easily

Today we are releasing a new, beta version of Tor Messenger, based on Instantbird, an instant messaging client developed in the Mozilla community.

What is it?

Tor Messenger is a cross-platform chat program that aims to be secure by default and sends all of its traffic over Tor. It supports a wide variety of transport networks, including Jabber (XMPP), IRC, Google Talk, Facebook Chat, Twitter, Yahoo, and others; enables Off-the-Record (OTR) Messaging automatically; and has an easy-to-use graphical user interface localized into multiple languages.

What it isn't...

Tor Messenger builds on the networks you are familiar with, so that you can continue communicating in a way your contacts are willing and able to do. This has traditionally been in a client-server model, meaning that your metadata (specifically the relationships between contacts) can be logged by the server. However, your route to the server will be hidden because you are communicating over Tor.

We are also excited about systems like Pond and Ricochet, which try to solve this problem, and would encourage you to look at their designs and use them too.

Why Instantbird?

We considered a number of messaging clients: Pidgin, Adam Langley's xmpp-client, and Instantbird. Instantbird was the pragmatic choice -- its transport protocols are written in a memory-safe language (JavaScript); it has a graphical user interface and already supports many natural languages; and it's a XUL application, which means we can leverage both the code (Tor Launcher) and in-house expertise that the Tor Project has developed working on Tor Browser with Firefox. It also has an active and vibrant software developer community that has been very responsive and understanding of our needs. The main feature it lacked was OTR support, which we have implemented and hope to upstream to the main Instantbird repository for the benefit of all Instantbird (and Thunderbird) users.

Current Status

Today we are releasing a beta version with which we hope to gain both usability and security related feedback. There have been three previous alpha releases to the mailing lists that have already helped smooth out some of the rougher edges.

Downloads (Updated)

Instructions

On Linux, extract the bundle(s) and then run: ./start-tor-messenger.desktop

On OS X, copy the Tor Messenger application from the disk image to your local disk before running it.

On all platforms, Tor Messenger sets the profile folder for Firefox/Instantbird to the installation directory.

Note that as a policy, unencrypted one-to-one conversations are not allowed and your messages will not be transmitted if the person you are talking with does not have an OTR-enabled client. You can disable this option in the preferences to allow unencrypted communication but doing so is not recommended.

Source Code

The Linux builds are reproducible: anyone who builds Tor Messenger for Linux should have byte-for-byte identical binaries compared with other builds from a given source. You can build it yourself and let us know if you encounter any problems or cannot match our build. The Windows and OS X builds are not completely reproducible yet but we are working on it.

What's to Come

Our current focus is security, robustness and user experience. We will be fixing bugs and releasing updates as appropriate, and in the future, we plan on pairing releases with Mozilla's Extended Support Release (ESR) cycle. We have some ideas on where to take Tor Messenger but we would like to hear what you have to say. Some possibilities include:

How To Help

Give it a try and provide feedback, requests, and file bugs (choose the "Tor Messenger" component). If you are a developer, help us close all our tickets or help us review our design doc. As always, we are idling on IRC in #tor-dev (OFTC) (nicks: arlolra; boklm; sukhe) and subscribed to the tor-talk/dev mailing lists.

Please note that this release is for users who would like to help us with testing the product but at the same time who also understand the risks involved in using beta software.

Thanks and we hope you enjoy Tor Messenger!

Update: For Windows 10 (and some Windows 7, 8) users who were experiencing an issue in Tor Messenger where it wouldn't start, we have updated the download links above with a newer version that fixes the problem described in bug 17453.

This will likely be a common problem. We have plans to allow controlling the Tor process from Tor Messenger so you can refresh your circuit and get a new exit node, but that may also not solve the problem. We had (rather, have) a similar issue with TorBirdy and Mike Hearn from Google replied on how to solve this: https://lists.torproject.org/pipermail/tor-talk/2012-October/025923.html. You can try this and it may involve giving your phone number, so be careful with that.

That requires you to disable tor, log into gmail to set a cookie, then reenable tor in the same browser for them to see your activity and whitelist you. How do you get the tor browser to stop using tor in order to do this?

I know it's not a proper solution by any shot. But this entire blocking behaviour by Google seems to be random and this is the only solution. In future release, you can refresh your circuit and get a new exit and that might help. But it's not a definitive solution. We know this is a huge problem and we will come up with better ways to handle this in the next release.

It is not a solution. You cannot solve this issue. Google raises an alert every time somebody tries to log into an account from an "unusual place". Google keeps track of where the account owner normally resides and throws a hissy fit every time s/he tries to log in from somewhere else, as determined by geoip location.

The issue is not limited to Tor. It happens when you use a VPN, too. Heck, it happens when you travel abroad, too!

In fact, the issue isn't limited to Google, either. Yahoo does the same. I don't use Facebook, but I suspect that they do the same, too.

There is not much point in supporting these chat protocols in a Tor-dependent messenger. I suggest that you remove them at least until Google, Yahoo, and all the other snoopers decide to become more Tor-friendly.

The NSA has found some weak links in the algorithms used to encrypt internet traffic. It means that whatever products or enhancements Tor developers are doing are vulnerable to US government snoops.

Matthew Green, one of the people who audited Truecrypt, postulated the NSA has solved some of the issues surrounding ECDLP (Elliptic Curve Discreete Logarithm Problem). "A riddle wrapped in a curve" (http://blog.cryptographyengineering.com/)

Deleting the folder should be enough since we do not write outside the folder. (Even the profile is in the folder.) If you find Tor Messenger is creating files outside its installation directory that are leaking information, please file a bug.

That site does not include the latest or previously existing features in Telegram, such as encryption of cloud chats, the password layer on top of 2FA, etc.

And essentially that boils down to hacking into one secret chat with one trillion dollars, which is pretty much not worth it. And supposedly you'd notice, as it could take over a day for the keys to exchange. In which you would know that the chat has been compromised. I can post more info.

Tor developers are a diverse group and I'm sure among them are many who hold the same beliefs as you.

The point was that JavaScript is a memory managed language, which theoretically eliminates a certain class of exploits. Further, as you said, Mozilla's JS VM has been in production for quite some time and seen some battle hardening.

I'm curious why you're not interested in integrating Ricochet's concept of secure, anonymous, server-less communications entirely inside the Tor network into Tor Messenger. It seems to align perfectly with the Tor Project's aims, especially as Tor Browser's functioning (accessing both the outside web and hidden services) is so analogous to Tor Messenger (accessing both outside third party IM servers and a Ricochet-style system of hidden service IM nodes).

Is it just a lack of resources (since you're so busy getting the baseline messaging client up and running)? Do you not like the Ricochet concept enough to integrate it? Do you think there aren't enough people who'd use it to be worth the development effort? Are there other important reasons?

I'm sure the Ricochet developers do good work, but the Tor Project would provide a better implementation, better support, and better auditing simply due to having more funding, better familiarity with Tor, and the sheer number of people focused on your products both inside and outside of the organization.

Are you planning on integrating the Ricochet concept into Tor Messenger in the future (near, medium, or distant/wishlist), or will that never occur?

We love Ricochet. That's why we made sure to point to it in the blog post. Many of us use both Ricochet and Tor Messenger.

The goal for Tor Messenger is to meet people where they are -- so you can have more safety on your side, while still interacting with your friends who e.g. use XMPP and OTR but haven't seen the light yet. While the goal of Ricochet (ok, one of the goals) is to give people a chat approach where there's no "middle", and thus no central point for the adversary to break in and snoop on things.

(In fact, we spent a while over the past few weeks trying to sort out whether the name 'Tor Messenger' would confuse people into thinking that we think this is the one true way, and we think approaches like Pond and Ricochet are not the one true way. We don't think that. We like both approaches.)

Whether one day the Tor Messenger client adds support for the Ricochet protocol is still a matter under discussion by the Tor Messenger folks and the Ricochet developer. One reason against is actually because the Ricochet person wants Ricochet to be an experience (i.e. including a client with good usability), not just a standardized protocol that all sorts of apps can implement and present to the user however they want. One argument on the other side though is that Ricochet is going to have a tough time being its own self-contained network, while also still using Qt (and thus not working well on mobile). More thinking to be done there for sure.

As for the "doing it inside Tor Messenger would provide better familiarity with Tor" angle, we've actually brought the main Ricochet person under our umbrella and we're happy to call him a Tor person now. So we help him, and he helps us, just as much as in the Tor Messenger case.

And lastly, on the funding angle, actually neither project has any funding currently. We're working on helping both of them to fix that.

Please keep in mind that you're not necessarily restricted to only using Ricochet's protocol for hidden service IM nodes, so if you are interested in the concept but can't come to an agreement with the Ricochet devs or for whatever reason can't integrate it into Tor Messenger, you could always develop your own standardized protocol (e.g. based on TorChat; though the benefits of not having to reinvent the wheel are obvious).

I hope it's possible to integrate Ricochet (or something similar) into Tor Messenger in the future, as they seem like a perfect fit, and I tend to favor single programs that do everything instead of multiple programs that do one thing each (more dev eyes/interest in a larger project, and it's harder to get non-tech users interested in using multiple programs for the same function). It's understandable, though, that the Ricochet developer may not want to lose control of his project (which might occur if it gets submerged into Tor Messenger).

Hi! There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.3.3.2-alpha from the usual place on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release some time in February.

Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.

Tor 0.3.3.2-alpha is the second alpha in the 0.3.3.x series. It introduces a mechanism to handle the high loads that many relay operators have been reporting recently. It also fixes several bugs in older releases. If this new code proves reliable, we plan to backport it to older supported release series.

Changes in version 0.3.3.2-alpha - 2018-02-10

Major features (denial-of-service mitigation):

Give relays some defenses against the recent network overload. We start with three defenses (default parameters in parentheses). First: if a single client address makes too many concurrent connections (>100), hang up on further connections. Second: if a single client address makes circuits too quickly (more than 3 per second, with an allowed burst of 90) while also having too many connections open (3), refuse new create cells for the next while (1-2 hours). Third: if a client asks to establish a rendezvous point to you directly, ignore the request. These defenses can be manually controlled by new torrc options, but relays will also take guidance from consensus parameters, so there's no need to configure anything manually. Implements ticket 24902.

Major bugfixes (netflow padding):

Stop adding unneeded channel padding right after we finish flushing to a connection that has been trying to flush for many seconds. Instead, treat all partial or complete flushes as activity on the channel, which will defer the time until we need to add padding. This fix should resolve confusing and scary log messages like "Channel padding timeout scheduled 221453ms in the past." Fixes bug 22212; bugfix on 0.3.1.1-alpha.