Tor 0.2.8.4-rc is released!

by nickm | June 15, 2016

Tor 0.2.8.4-rc has been released! You can download the source from the Tor website. Packages should be available over the next week or so.

Tor 0.2.8.4-rc is the first release candidate in the Tor 0.2.8 series. If we find no new bugs or regressions here, the first stable 0.2.8 release will be identical to it. It has a few small bugfixes against previous versions.

PLEASE NOTE: This is a release candidate. We think that we solved all
of the showstopper bugs, but crucial bugs may remain. Please only run
this release if you're willing to test and find bugs. If no
showstopper bugs are found, we'll be putting out 0.2.8.5 as a stable
release.

Changes in version 0.2.8.4-rc - 2016-06-15

  • Major bugfixes (user interface):
    • Correctly give a warning in the cases where a relay is specified by nickname, and one such relay is found, but it is not officially Named. Fixes bug 19203; bugfix on 0.2.3.1-alpha.
  • Minor features (build):
    • Tor now builds once again with the recent OpenSSL 1.1 development branch (tested against 1.1.0-pre5 and 1.1.0-pre6-dev).

 

  • Minor features (geoip):
    • Update geoip and geoip6 to the June 7 2016 Maxmind GeoLite2 Country database.
  • Minor bugfixes (compilation):
    • Cause the unit tests to compile correctly on mingw64 versions that lack sscanf. Fixes bug 19213; bugfix on 0.2.7.1-alpha.
  • Minor bugfixes (downloading):
    • Predict more correctly whether we'll be downloading over HTTP when we determine the maximum length of a URL. This should avoid a "BUG" warning about the Squid HTTP proxy and its URL limits. Fixes bug 19191.

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

June 16, 2016

Permalink

What changes should be made to the configuration of a running v0.2.7.6 relay when upgrading to v0.2.8.4+?

Put another way, can I just upgrade the code and forget it, or are there other changes I can/should make to accommodate the newer version?

Thanks.

Anonymous (not verified) said:

June 17, 2016

Permalink

A good privacy improvement is using a random amount (min 1+3(for Bridge users - 1+2), max user-defined) of circuits.

We need to take in-to account that a large list of Exit nodes can be run by a single entity.

Imagine the following scenario:
A single entity is running 100 Exit nodes. A Tor Browser user accesses vbdvexcmqi.oedi.net, if Tor Browser user is unlucky(we all have chance on the default settings where we don't use Bridge) he is using only Nodes from the single entity. The single entity now can connect the dots and know the IP address and the browser address of Tor Browser user because he is the Entry (unless we use Bridge), The first, the second and the Exit node just because on the single fact that default users always use minimum and maximum 4 nodes.

If we use a Bridge then the single entity can only get the IP address of bridge. This is usually improved in case of Hidden Services that use multiple Bridges.

Conclusion:
Even with more circuits the scenario can and will happen but will never be 100% sure because they don't know the circuit count.

Thank you for reading and please take this in to consideration. Can't wait to read your answer.

that possibility is known since long time and torproject already did several actions&fixes do minimize correlation threads! if you fear such a szenario cause you need very high safety you should of cause add some care to additional protect yourself, like using public accesspoint&machine and such.

Sure, the scenario you outline is possible. But 100% surety is actually easy for your attacker if traffic from a compromised exit node (in a chain of compromised relays) is seen leaving the Tor network.

It's also already possible today to use more than 3 relays if you wish. You'll take a performance hit, but maybe you'll decide that's okay. Maybe it'll improve your chances of anonymity. Maybe not, too.

Anonymous (not verified) said:

June 18, 2016

Permalink

"We need to take in-to account that a large list of Exit nodes can be run by a single entity."

Feel free to document this assumption, i know it's possible but it really never did happen.

Anonymous (not verified) said:

June 19, 2016

Permalink

great
barki@ninja-network:~$ apt-get install tor
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
barki@ninja-network:~$ sudo apt-get install tor
sudo: unable to resolve host ninja-network
[sudo] password for barki:
Reading package lists... Done
Building dependency tree
Reading state information... Done
tor is already the newest version (0.2.7.6-1ubuntu1).
tor set to manually installed.
The following packages were automatically installed and are no longer required:
linux-headers-4.4.0-23 linux-headers-4.4.0-23-generic
linux-image-4.4.0-23-generic linux-image-extra-4.4.0-23-generic
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Anonymous (not verified) said:

June 20, 2016

Permalink

so this may sound like a stupid question but I'm 20 years of age and lol I'm not really that smart with computers so my question is. do you have to know what you are doing to get on the dark web i mean i have downloaded to tor but it still won't let me on can anyone help or am i sol