tor 0.2.4.22 released
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.
- Block authority signing keys that were used on authorities
- 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.
- Fix a memory leak that could occur if a microdescriptor parse
- 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.
- The relay ciphersuite list is now generated automatically based on
- 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.
- When running a hidden service, do not allow TunneledDirConns 0:
- 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.
- Avoid sending a garbage value to the controller when a circuit is
- 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.
- Stop leaking memory when we successfully resolve a PTR record.
- 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.
- Avoid 60-second delays in the bootstrapping process when Tor is
- 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.
- Give the correct URL in the warning message when trying to run a
- Minor bugfixes (compilation):
- Fix a compilation error when compiling with --disable-curve25519.
Fixes bug 9700; bugfix on 0.2.4.17-rc.
- Fix a compilation error when compiling with --disable-curve25519.
- 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.
- Downgrade the warning severity for the the "md was still
- 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.
- When we run out of usable circuit IDs on a channel, log only one
- 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.
- Decrease the lower limit of MaxMemInCellQueues to 256 MBytes (but
- 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.
- Correctly document that we search for a system torrc file before
Comments
Please note that the comment area below has been archived.
What is "target relay"? what
What is "target relay"? what does it mean?
"a relay that a bad guy
"a relay that a bad guy picks to use the attack on"
How can the bad guy run a
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.
Ah ha. The phrase is "to run
Ah ha. The phrase is "to run a relay out of ram" -- like to run a cowboy out of town. As in, to cause it to be out of ram.
See definition 1 under 'transitive verb' at
http://www.merriam-webster.com/dictionary/run
This is awesome! especially
This is awesome! especially the stronger ciphersuites implemented. keep it up.
In my first attempt to use
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
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!
I was going to one of my own
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
I have tried several of the
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.
enables selection of (fast)
enables selection of (fast) GCM
ciphersuites
"[...]enables selection of
"[...]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
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).
I enjoyed reading David
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
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.
Yeah, neat. But if the
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?
6 more OpenSSL
6 more OpenSSL vulnerabilities discovered, some of them existed for over 15 years.
http://www.openssl.org/news/secadv_20140605.txt
https://www.imperialviolet.org/2014/06/05/earlyccs.html
I've just noticed that by
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
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
Thanks you for your
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!
Filed
Filed https://trac.torproject.org/projects/tor/ticket/12404
Is it ok to replace
Is it ok to replace libssl32.dll and libeay32.dll with newer versions than those provided in the Windows Vidalia bundle?
Sorry, I meant is it ok to
Sorry, I meant is it ok to replace ssleay32.dll and libeay32.dll with newer versions than those provided in the Windows Vidalia bundle?
"This is a slightly belated
"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?
I believe
I believe so.
https://lists.torproject.org/pipermail/tor-qa/2014-June/000415.html
Is the ROP hack code(general
Is the ROP hack code(general BACKDOOR?) in OpenSSL -written from OpenSSL programer Andy Polyakov- still a problem?
Good thing it's open
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.
Thanks for the Windows
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
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? :)
What's the difference
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?
https://lists.torproject.org/
https://lists.torproject.org/pipermail/tor-commits/2014-June/075678.html
"update Windows packages for new OpenSSL"