Tor Messenger 0.3.0b2 is released

by sukhbir | December 29, 2016

We are pleased to announce another public beta release of Tor Messenger. This release features important improvements to the stability and security of Instantbird. All users are encouraged to upgrade.

Tor Messenger 0.3.0b1 users will be automatically prompted to install the update (similar to Tor Browser). On installing and restarting, the update will be applied; your account settings and OTR keys will be preserved.

Downloads

Please note that Tor Messenger is still in beta. The purpose of this release is to help test the application and provide feedback. At-risk users should not depend on it for their privacy and safety.

Linux (32-bit)

Linux (64-bit)

Windows

macOS

sha256sums-signed-build.txt
sha256sums-signed-build.txt.asc

The sha256sums-signed-build.txt file containing hashes of the bundles is signed with the key 0xB01C8B006DA77FAA (fingerprint: E4AC D397 5427 A5BA 8450  A1BE B01C 8B00 6DA7 7FAA). Please verify the fingerprint from the signing keys page on Tor Project's website.

Changelog

Tor Messenger 0.3.0b2 -- 29 December, 2016

  • All Platforms
    • Use the tor-browser-45.6.0esr-6.0-1-build1 tag on tor-browser
    • Use the THUNDERBIRD_45_6_0_RELEASE tag on comm-esr45
    • Update ctypes-otr to 0.0.4
    • Update tor-browser to 6.0.8
    • Don't allow javascript: links in themes
    • Permit storing cert. exceptions in private browsing mode
    • Bugzilla 1321420: Add a pref to disable JavaScript in browser requests
    • Bugzilla 1321641: Disable svg and mathml in content

Comments

Please note that the comment area below has been archived.

December 29, 2016

Permalink

"Don't allow javascript" "Disable svg and mathml in content"

Does that mean that my MathJax plugin will no longer work ?

Would be great if someone could give an answer and say if DANE/DNSSEC actually makes sense cos it seems that not many applications (including Thunderbird) that support them.

December 29, 2016

Permalink

A question:

What happens if the middle node is an very old, buggy, outdated 1024-bit crypto Tor 0.2.4.20?
The Exit is using this old outdated 1024-bit crypto, too?

Great question, I'm also looking for an answer to that. It seems the Tor Project recently volunteerily removed relays with Tor versions before 2.4 just after the launch of Tor 0.2.9

I have no idea what this has to do with Tor Messenger, but... No.

a) 0.2.4.20 supports ntor.
b) It's on a per hop basis.
c) Prior to 0.2.9.8 at least one hop must use ntor.
d) Including and after 0.2.9.8, all hops must use ntor
3) The TAP handshake is old, but isn't totally broken.

December 31, 2016

Permalink

I have experience to explain others (newbies) how to connect to onion XMPP (including registering the account) using tor messenger (TM). That was a real headache. The more options the user is required, the more probable he will type something wrong. It is especially hard with onion servers. I believe all options must be on single page, so user should not list windows by pressing "next" 10 times and remember, where and what was written. The good way is CoyIM from SubgraphOS project: it is much easier to use. I would like to see something similar for TM.

In particular, option "username" is confusing, because actual username in XMPP is jid, not just nickname.There should be the single option "jabber id", and server must be taken from that by default (if option host is not set). CoyIM did it even better: it recognizes that XMPP server has some onion name and use that automatically (the list is predefined with matches between names (DNS and onion) by CoyIM developers).

Another headache is forceful TLS with onion services. I chose "allow sending password unencrypted" and disabled OSCP in preferences, but still TM tries to establish TLS connection (usually, onion XMPP server has also DNS name and support for clearnet connections, so jid is "nick@dnsname.domain" and server is "xxx.onion"). It results in error (surely, onion site is not valid for TLS certiciate), which I must manually overcome by clicking and adding it to exceptions (and do this every time I start TM). Now imagine I must tell all this stuff to newbies who know nothing about XMPP or Tor before starting Tor Messenger.

The last, but not least, is the impossibility to use different tor chains for different tor accounts. This is in proposal, AFAIK, but not yet implemented. I like how it is done in CoyIM (in particular, they already implemented it), and would like to see something similar for TM.

You make some good points. The UI is probably almost completely from Instantbird and not specific to Tor Messenger. The .onion (differing from the JID and disabling TLS) is confusing to some users also, but hardcoding .onion addresses of servers is a hack, and there needs to be some way for the server to differ from the JID.

Your last point is an important one I hadn't though of. You could set IsolateDestAddr in torrc if you're only connecting to different servers (and not multiple accounts on the same server), but I'm not sure if you can specify different SOCKS passwords for each account (if so, this should really be done by default).

If you're only worried about your own anonymity (and not the security of the conversation or the other person's anonymity), the absolute easiest way is to point the other user to ConverseJS.org and give them a username and password.

there needs to be some way for the server to differ from the JID.

Surely. It must work in same way as tor browser: defaults must be OK for most of users, but advanced users must have a way to change all settings.

You could set IsolateDestAddr in torrc if you're only connecting to different servers (and not multiple accounts on the same server), but I'm not sure if you can specify different SOCKS passwords for each account (if so, this should really be done by default).

I speak exactly about multiple accounts on the same server. All this staff is in tickets for many years (see arlo's comment), but none is yet implemented.

If you're only worried about your own anonymity (and not the security of the conversation or the other person's anonymity), the absolute easiest way is to point the other user to ConverseJS.org and give them a username and password.

That's true, but we should tend to the best, where everybody is anonymous and secure by default.

January 05, 2017

In reply to arlo

Permalink

Since CoyIM is getting all this right though, why not just use that?

No, it isn't getting all right. But it has some good features. In general it has its own pros and cons. It is too young project, which is in practical way maybe less convenient for experienced users. If you want to know main problems of CoyIM, here they are:

  • Neither host nor port of Tor can be changed (the only way now is to do redirection with iptables).
  • Custom jabber server cannot be specified. You can only select XMPP server from predefined list of about 5 servers.
  • AFAIK, it is not possible to disable OTR. So, in rare cases when I really need to send offline message to user, I cannot do that.
  • No automatic updates.

Interesting, in CoyIM random delays are introduced before connecting different JIDs, so different accounts cannot be easily correlated as always connecting simultaneously.

January 06, 2017

In reply to yawning

Permalink

Great, that the golang crypto/tls-library now (since go v1.5, 19 August 2015) includes some current ciphers but unfortunately it still uses the ciphers "as specified in RFC 5246", ie it includes RC4 even so RFC 7465 " Prohibiting RC4 Cipher Suites" updates RFC 5246.

and the bottom of the package of the crypto/tls page
Bugs
☞The crypto/tls package does not implement countermeasures against Lucky13 attacks on CBC-mode encryption. See http://www.isg.rhul.ac.uk/tls/TLStiming.pdf and https://www.imperialviolet.org/2013/02/04/luckythirteen.html.

> Great, that the golang crypto/tls-library now (since go v1.5, 19 August 2015) includes some current ciphers

"agl committed on Aug 29, 2013"
https://github.com/golang/go/commit/2fe9a5a3e826d8b2dc45652e1b5d1c23eee…

(128 bit AES is fine against anyone that can't run Grover's Algorithm, and anyone that can, can much more easily run Shor's rendering the point moot.)

> but unfortunately it still uses the ciphers "as specified in RFC 5246", ie it includes RC4 even so RFC 7465 " Prohibiting RC4 Cipher Suites" updates RFC 5246.

So override the cipher suites. (The `Config` struct has a `CipherSuites` member, which does exactly what you would expect it to do).

January 06, 2017

In reply to yawning

Permalink

I looked at it from a user's perspective not from the point of go programmer (what I'm not). It just that someone recommended a secure messenger that uses golang and I thought golang doesn't use/support current ciphers and I was wrong it does use them. But unfortunately the their crypto library doesn't honor RFC7525 (May 2015)

o Implementations MUST NOT negotiate RC4 cipher suites.
Rationale: The RC4 stream cipher has a variety of cryptographic
weaknesses, as documented in [RFC7465]. Note that DTLS
specifically forbids the use of RC4 already.

cf. "Prohibiting RC4 Cipher Suites" RFC 7465

but

o Implementations SHOULD NOT negotiate cipher suites that use
algorithms offering less than 128 bits of security.

(e.g., 168-bit 3DES) have an effective key length that is smaller
than their nominal key length (112 bits in the case of 3DES).
Such cipher suites should be evaluated according to their
effective key length.

Implementations SHOULD NOT negotiate cipher suites based on RSA
key transport, a.k.a. "static RSA"

Rationale: These cipher suites, which have assigned values
starting with the string "TLS_RSA_WITH_*", have several drawbacks,
especially the fact that they do not support forward secrecy.

Don't get me wrong, I'm just a user and appreciate the work that all the free software programmer put into their projects (as you do for eg with sandboxing the tbb), it just that I was concerned that a XMPP client that aims at being secure-by-default might use a cryptolibrary that's problematic by not honoring the current standards.

I was concerned that a XMPP client that aims at being secure-by-default might use a cryptolibrary that's problematic by not honoring the current standards.

Modern secure-by-default XMPP messengers user Tor and onion services with TLS completely disabled (do you know TLS is not good for anonymity?). In case of CoyIM, which mainly prefer onion services for XMPP, not very well TLS may be not a big issue.

Keep in mind, that with Tor we can and should forget about TLS. It is deprecated technology. Anything that needs to be authenticated and encrypted end-to-end must use onion services.

I tried it, too. And I just choose an unregistered user name and as Server "irc.oftc.net" --> tls/ssl & port is set on the following page.
Than it took a few minutes to enter the irc server (and at least on attempt it failed completely, maybe because the exit was banned by oftc. Is there away to reconnect/change the circuit without restarting TM? )

Unfortunately, Tor Messenger shows in the whois information that I'm using Instantbird, why?

> Unfortunately, Tor Messenger shows in the whois information that I'm using Instantbird, why?

What would you prefer it to show? Tor Browser sets Firefox as its user agent.

January 03, 2017

In reply to arlo

Permalink

But all the other irc client just don't show the info, do they? Isn't this just an Instantbird-thing and if so would it better not to show it or is it for other reason obvious what client I'm using ?


WHOIS information for arlolra:
Name: arlolra
Connected to: helix.oftc.net (Umeå, Sweden)
Connected from: ~Instantbi@0001ba07.user.oftc.net
Registered: Yes

WHOIS information for sukhe:
Name: sukhe
Connected to: larich.oftc.net (Corvallis, OR, USA)
Connected from: ~sukhe@00017e0c.user.oftc.net
Registered: Yes

Would be a good idea to "preset" settings for the tor project's main irc channel on oftc? (so that user can get there by just clicking, ok)

On the other hand, Tor Messenger requires you to use irc commands (/join /list etc.) instead of just clicking on some buttons, maybe it's just not a beginner-friendly irc client in the beginning.

January 05, 2017

In reply to arlo

Permalink

Thanks for the good note! (I had missed it somehow)

BTW and IMHO -
- if I went into the trap with connecting to the IRC
(inserting "ircs://irc.oftc.net:6697" line instead of "irc.oftc.net" AND\OR irc-server just rejected exit node - now it is hard to say what was the exact reason of the fail - I had tried several different efforts and failed to connect all the time - only because of I decided to post my question I can use messenger now)
- thus other people may even drop using "Tor Messenger" only because of such bugs (or "features" - does not matter actually how they can be called as)
- so may be I can create defect somehow or even series of defects with exact reproduction-scenario?

Can you tell me please -
- what is the best way to start the process? - e.g. is it reasonable to discuss in the IRC first or where?
So what should I do if I think that - "I found defect!" ?

Thanks.

P.S. To be clear - now I can use Tor Messenger with OFTC but only because I posted the question here - in other situation a user may just drop using the tool as it "does not work from the box" IMHO (or user doing wrong steps from the Messenger's point of view - does not matter actually). Once again - thanks for the replays!

If their a usability or user interface issues you could also file a bug report (https://trac.torproject.org/projects/tor/report/1) and/or maybe even work on the wiki: https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger/FAQ)

Unofficial Documentation
Most of the content here is written by volunteers from around the world. If you find a topic you want to fix, expand, or create, please either create an account or use the multi-user account cypherpunks with the password writecode

https://trac.torproject.org/projects/tor

see also the reply to
https://blog.torproject.org/blog/tor-messenger-030b2-released#comment-2…

January 03, 2017

Permalink

Tor Messenger seems to sow in the irc WhoIs info that I'm using Instantbird, most other messenger like HexChat don't -- wouldn't it be better to change this?