tor 0.2.4.22 released

by phoul | June 4, 2014

This is a slightly belated announcement for the release of tor 0.2.4.22. Going into the future, we're planning to publish this information on the blog shortly after it is sent to tor-announce.

Release information is always published first on tor-talk.

Tor 0.2.4.22 backports numerous high-priority fixes from the Tor 0.2.5 alpha release series. These include blocking all authority signing keys that may have been affected by the OpenSSL "heartbleed" bug, choosing a far more secure set of TLS ciphersuites by default, closing a couple of memory leaks that could be used to run a target relay out of RAM, and several others.

Here is the complete changelog:
Changes in version 0.2.4.22 - 2014-05-16:

  • Major features (security, backport from 0.2.5.4-alpha):
    • Block authority signing keys that were used on authorities
      vulnerable to the "heartbleed" bug in OpenSSL (CVE-2014-0160). (We
      don't have any evidence that these keys _were_ compromised; we're
      doing this to be prudent.) Resolves ticket 11464.
  • Major bugfixes (security, OOM):
    • Fix a memory leak that could occur if a microdescriptor parse
      fails during the tokenizing step. This bug could enable a memory
      exhaustion attack by directory servers. Fixes bug 11649; bugfix
      on 0.2.2.6-alpha.
  • Major bugfixes (TLS cipher selection, backport from 0.2.5.4-alpha):
    • The relay ciphersuite list is now generated automatically based on
      uniform criteria, and includes all OpenSSL ciphersuites with
      acceptable strength and forward secrecy. Previously, we had left
      some perfectly fine ciphersuites unsupported due to omission or
      typo. Resolves bugs 11513, 11492, 11498, 11499. Bugs reported by
      'cypherpunks'. Bugfix on 0.2.4.8-alpha.
    • Relays now trust themselves to have a better view than clients of
      which TLS ciphersuites are better than others. (Thanks to bug
      11513, the relay list is now well-considered, whereas the client
      list has been chosen mainly for anti-fingerprinting purposes.)
      Relays prefer: AES over 3DES; then ECDHE over DHE; then GCM over
      CBC; then SHA384 over SHA256 over SHA1; and last, AES256 over
      AES128. Resolves ticket 11528.
    • Clients now try to advertise the same list of ciphersuites as
      Firefox 28. This change enables selection of (fast) GCM
      ciphersuites, disables some strange old ciphers, and stops
      advertising the ECDH (not to be confused with ECDHE) ciphersuites.
      Resolves ticket 11438.
  • Minor bugfixes (configuration, security):
    • When running a hidden service, do not allow TunneledDirConns 0:
      trying to set that option together with a hidden service would
      otherwise prevent the hidden service from running, and also make
      it publish its descriptors directly over HTTP. Fixes bug 10849;
      bugfix on 0.2.1.1-alpha.
  • Minor bugfixes (controller, backport from 0.2.5.4-alpha):
    • Avoid sending a garbage value to the controller when a circuit is
      cannibalized. Fixes bug 11519; bugfix on 0.2.3.11-alpha.
  • Minor bugfixes (exit relay, backport from 0.2.5.4-alpha):
    • Stop leaking memory when we successfully resolve a PTR record.
      Fixes bug 11437; bugfix on 0.2.4.7-alpha.
  • Minor bugfixes (bridge client, backport from 0.2.5.4-alpha):
    • Avoid 60-second delays in the bootstrapping process when Tor is
      launching for a second time while using bridges. Fixes bug 9229;
      bugfix on 0.2.0.3-alpha.
  • Minor bugfixes (relays and bridges, backport from 0.2.5.4-alpha):
    • Give the correct URL in the warning message when trying to run a
      relay on an ancient version of Windows. Fixes bug 9393.
  • Minor bugfixes (compilation):
    • Fix a compilation error when compiling with --disable-curve25519.
      Fixes bug 9700; bugfix on 0.2.4.17-rc.
  • Minor bugfixes:
    • Downgrade the warning severity for the the "md was still
      referenced 1 node(s)" warning. Tor 0.2.5.4-alpha has better code
      for trying to diagnose this bug, and the current warning in
      earlier versions of tor achieves nothing useful. Addresses warning
      from bug 7164.
  • Minor features (log verbosity, backport from 0.2.5.4-alpha):
    • When we run out of usable circuit IDs on a channel, log only one
      warning for the whole channel, and describe how many circuits
      there were on the channel. Fixes part of ticket 11553.
  • Minor features (security, backport from 0.2.5.4-alpha):
    • Decrease the lower limit of MaxMemInCellQueues to 256 MBytes (but
      leave the default at 8GBytes), to better support Raspberry Pi
      users. Fixes bug 9686; bugfix on 0.2.4.14-alpha.
  • Documentation (backport from 0.2.5.4-alpha):
    • Correctly document that we search for a system torrc file before
      looking in ~/.torrc. Fixes documentation side of 9213; bugfix on
      0.2.3.18-rc.

Comments

Please note that the comment area below has been archived.

June 06, 2014

In reply to arma

Permalink

How can the bad guy run a target relay if the relay's already running? This sentence "closing a couple of memory leaks that could be used to run a target relay out of RAM" is very confusing.

June 05, 2014

Permalink

In my first attempt to use Tor I got a message that the IP address I was using was blacklisted in HTTBL. Is this to be expected?

It totally depends what sites you go to. Alas, there is a trend that many websites in the world prefer a Facebook login or the like and don't want to give you service otherwise. We need to fight that trend -- please help!

June 06, 2014

In reply to arma

Permalink

I was going to one of my own Drupal sites which has a spam blocking module which accesses HTTBL ... I do not think the site should matter since all it does is access HTTBL and if it is blocked there it rejects the connection.
I just attempted to connect to one of my sites and got this error message:

We're sorry!
We cannot let you access our website at this time.

Your IP address (91.213.8.236) has been identified as a possible source of suspicious, robotic traffic and has been greylisted by Project Honeypot.

If you are an actual human visitor who can read simple instructions,
you may try getting whitelisted on http://tcan.ca/httpbl/whitelist.

When I went to Honeypot to check the IP address I got this info:

Honey Pot System commented...
WHITELIST NOTICE: This IP has been REMOVED from Project Honey Pot whitelists; bad activity was encountered.
September 19 2013 11:56 PM

June 06, 2014

In reply to arma

Permalink

I have tried several of the sites I manage and most of them block (via HTTBL) the IP addresses of the proxy servers that this browser uses. I think this is a potentially serious issue. I have never been blocked using my regular IP address.

June 05, 2014

Permalink

"[...]enables selection of (fast) GCM ciphersuites[...]"
In the past NSA engineers have tried pushing this special Counter Mode(GCM) -for VOIP?- and get legitimate strong headwind.
Is this a problem for Tor, too??

We're just using it for the link encryption, to make the flows look like Firefox talking to Apache.

If indeed there's a subtle flaw in the GCM algorithm (I don't know of one, but who knows), then the worst case is that our link encryption is gone -- good thing we still have the circuit-level encryption at each hop (and it is not based on GCM).

June 05, 2014

Permalink

I enjoyed reading David Fifield's, A Child’s Garden of Pluggable Transports. I'm excited about ScrambleSuit being added to the Tor Browser Bundle, because it randomizes the size and timing of packets.

Unfortunately, ScrambleSuit also uses more bandwidth. But I've really been looking forward to some protections against correlation attacks.

Thank you for your hard work!

https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPlugga…

How much more bandwidth does it use in practice? Somebody should study that.

Also, while I too would like protection against correlation attacks, it's unclear that ScrambleSuit helps here. I'm not saying it doesn't, just that it's an open research question.

And finally, yes, I agree, David's page is really neat.

June 06, 2014

In reply to arma

Permalink

Yeah, neat. But if the bridge's domain name spells tor (as some do), the creator of the plug and all his users are fooling themselves. What about resolving/showing the bridge's domain names?

June 08, 2014

Permalink

I've just noticed that by disabling the curves cryptography with --disable-curve25519, compiling it under Linux and restricting a few entry points - some potentially rogue countries, which is reasonable if you find yourself in a region that isn't that democratic or just want to avoid one, the actual version of tor, while still loading without any error messages it reaches 80% and then it stalls. Looking at the process traffic I could observe that it tries to handshake with a few peers and after a while it ceases to attempt any further connections. Worth to mention that tor 2.3.25 runs well with my actual torrc config file. I haven't tried an ssldump on those connections but I guess it's an issue with the prioritization of the new nTor protocol and maybe the peers are not capable of handling it. Could be that the majority of the entry points are still running tor 2.3.25 or maybe nTor is all about ECDHE and I disabled those curves, which I still don't trust but that's my personal opinion.

Additionally, there are some interesting news coming from the OpenSSL team, news I couldn't find any reference about here on the tor project site. Some bugs were recently found and patched in the new version 1.0.1h, bugs that have the same security impact, if not worse, as the Heartbleed bug had. OpenSSL's Security Advisory is worth reading:
https://www.openssl.org/news/secadv_20140605.txt

If you as a client don't speak curve25519, then you will indeed be unable to use the NTor circuit handshake. The TAP handshake queues are still being mobbed by the botnet clients, so that's a confounding factor. So I'm not sure if you have a bug here or what. Please explore more, and open a ticket on trac if you get details -- for example, steps to reproduce that have more precise details than e.g. "a few entry points". Thanks!

As for this week's openssl issue, it is bad but nowhere near as bad as heartbeat.
https://lists.torproject.org/pipermail/tor-talk/2014-June/033161.html

June 14, 2014

In reply to arma

Permalink

Thanks you for your reply!

You're right, I don't speak curve25519 because I disabled it before compiling the tor binary with the help of the configuration directive --disable-curve25519.
And since your team is such a big fan of the curves crypto that you choose to make NTor totally dependent on it, furthermore recently adopting the policy that at least one of the first three connections should be Ntor(curve25519), it's obvious that I can't get in the tor network, no further investigation necessary ATM I presume.

I'd suggest to remove that "--disable-curve25519" directive because it has no sense at all in the actual context.

It's a pity though, and maybe a dangerous direction to impose curve25519 on all your peers and not letting them choose other cryptography. I guess you could embed the curves directly into tor and drop the need for the OpenSSL library. You'll be better of by not depending on some external (buggy) libraries I guess.

I find the curves cryptography primitive and way too simplistic, if allowed - lame. Furthermore from a traffic analysis point of view, due to the low adoption of curves crypto, one cannot hide easily in the crowd and due to the clear and distinctive patterns curves crypto is generating, the curves encrypted streams will stink like tor and not smell like some usual https traffic.

Keep going & growing & doing a good job!

June 09, 2014

Permalink

Is it ok to replace libssl32.dll and libeay32.dll with newer versions than those provided in the Windows Vidalia bundle?

June 09, 2014

Permalink

Sorry, I meant is it ok to replace ssleay32.dll and libeay32.dll with newer versions than those provided in the Windows Vidalia bundle?

June 09, 2014

Permalink

"This is a slightly belated announcement for the release of tor 0.2.4.22."

Will this be incorporated into a new TBB to be released shortly?

June 09, 2014

Permalink

Is the ROP hack code(general BACKDOOR?) in OpenSSL -written from OpenSSL programer Andy Polyakov- still a problem?

Good thing it's open source?

This isn't really the right forum for discussing it -- that is, you won't get many good thoughtful answers about it here I'm afraid.

June 10, 2014

Permalink

Thanks for the Windows Expert Bundle build. Will there be an Unstable build so we can test the alpha before it becomes a release?

I believe you can just snag the tor.exe out of the normal alpha TBB for Windows. You might have to grab a few dll's or something. You are an expert after all, right? :)

June 12, 2014

Permalink

What's the difference between "tor-0.2.4.22-win32.exe" (20-May-2014) and "tor-0.2.4.22-win32-1.exe" (06-Jun-2014) ?
Some bug / security fixes?