June 2010 Progress Report

by phobos | July 13, 2010

New releases

  • On June 1, we released the latest Tor Browser Bundle for Linux, version 1.0.7. This is a compatibility release to allow the bundle to work on a wider variety of Linux distributions.
  • On June 2, updated the Vidalia bundle for OS X PowerPC to include Vidalia 0.2.9.
  • On June 14, we released orbot 0.0.8. This is a maintenance release to fix issues discovered with Android 2.2.
  • On June 17, Tor and the EFF released a Firefox extension called HTTPS Everywhere. The goal is to enable encrypted website viewing by default. More about this release at https://ocewjwkdco.tudasnich.de/blog/https-everywhere-firefox-addon-helps-y….
  • Damian continues to improve and release new versions of ARM, the console-based anonymizing relay monitor, http://www.atagar.com/arm/. Consider it to be like the graphical control application, Vidalia, for relays without a graphical environment.

Design, develop, and implement enhancements that make Tor a better tool for users in censored countries.

  • We updated the geoip mapping database to the Maxmind GeoLite Country database in tor after an analysis of various geoip mapping databases. The Maxmind GeoLite Country database has more accurate mappings for many parts of the world, such as Iran, SouthEast Asia, and many African countries.
  • China’s Great Firewall continues blocking connections to the public Tor relays. They also updated their blocking to include bridge relays published via email and https websites. We conducted further research into the blocking mechanisms from inside China. A detailed analysis shows China GFW is blocking 90% of the published bridges in the https and smtp pools. The blocking is simply IP Address and TCP port combinations. Bridge relays that have been seeded into various social networks in China as well as new bridge addresses continue to work well.
  • In late June, we started receiving many reports that Nigerian internet providers are blocking many circumvention tools, Tor included. Data about the blocking methods implemented are sparse right now, but we’re continuing to work with a few smart Nigerians to reverse-engineer the blocking regime. More details about this block at https://ocewjwkdco.tudasnich.de/blog/dear-nigerians-help-us-help-you.

Measures of the Tor Network
https://ocewjwkdco.tudasnich.de/files/exit-2010-06.png
This graph shows the total quantity of relays and quantity of exit relays in june 2010. Exit relay capacity is one of the potential bottlenecks that affects the overall performance of Tor. The more exit relays we have, the faster it seems to browse the open Internet. As seen in late June, a researcher using PlanetLab hooked up 512 relays to the Tor network for their research into cloud computing and scaling effects on the Tor Network. Before contacting PlanetLab, we removed all 512 nodes from the network consensus so users couldn’t use the suspect relays. We contacted the researcher and the relays were subsequently disabled.

https://ocewjwkdco.tudasnich.de/files/networksize-2010-06.png
This graph shows the total quantity of relays and the total quantity of bridges in June 2010. The quantity of bridges is stable throughout the month. As seen in late June, a researcher using PlanetLab hooked up 512 relays to the Tor network for their research into cloud computing and scaling effects on the Tor Network. Before contacting PlanetLab, we removed all 512 nodes from the network consensus so users couldn’t use the suspect relays. We contacted the researcher and the relays were subsequently disabled.

https://ocewjwkdco.tudasnich.de/files/torperf-50kb-torperf-6m.png
This graphs shows how many seconds it took to complete a 50KB download from a standard Tor client. This measurement is from the server torperf, located in Chicago, Illinois. As you can see, latency dropped dramatically over the month for the second month in a row. We believe this is due to the fixes for relays in 0.2.1.26 allow relays to handle older clients flooding circuit requests to relays. As some relays were overloaded and dropped out of the network, the remaining relays had to handle an increasing load of users. Also, we have a budding competition between individuals looking to run the highest bandwidth relays. TorServersdotNet, http://www.torservers.net/, starting running some very high bandwidth relays to increase performance and provide a way for non-technical users to support tor through combined financial donations in exchange for Tor servers. We’re also looking to run this measurement software on a linux client connected to a standard dial-up modem to see how Tor fares in extremely low-bandwidth environments.

Outreach and Advocacy

Preconfigured privacy (circumvention) bundles for USB or LiveCD.
Erinn continues to work on a Tor Browser Bundle for Apple’s OS X. Erinn continues to improve Tor Browser Bundle for Linux with feedback from initial users and other volunteer developers.

Bridge relay and bridge authority work.
Andrew published a template configuration file for tor relays to be a bridge automatically. It seems some relay operators are confused as to configuring their relay as a bridge. The configuration template is at https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/src/config/torrc… and will be included in future Tor releases.

Andrew created some experimental “bridge by default“ bundles for Microsoft Windows. The idea is to use existing technology and see if we can get users to be bridges by default without any additional configuration. Intitial testing shows it works well if the upstream router or NAT device has Universal Plug and Play (UPNP) enabled. The largest obstacle is still the manual configuration of firewalls, routers, and NAT devices if UPNP is not enabled by default. More details about this experiment are at https://ocewjwkdco.tudasnich.de/blog/technology-preview-bridge-default-micr….

Scalability, load balancing, directory overhead, efficiency.
Mike spent a lot of effort and research into optimizing the circuit based timing (CBT) codebase. CBT is how clients measure the performance of their tor circuits to better optimize performance.
The changelog of the fixes is:
• Major bugfixes:
– Ignore negative and large timeout values that can happen during a suspend or hibernate. These values caused various asserts to fire in the circuit build times code, crashing Tor. Bug 1245, bugfix on 0.2.2.2-alpha.
– Alter calculation of Pareto distribution parameter ’Xm’ for Circuit Build Timeout learning to use the weighted average of the top N=3 modes. This should improve the timeout calculation in some cases, and prevent extremely high timeout values. Bug 1335, bugfix on 0.2.2.2-alpha.
– Implement a filtering step to recompute synthetic build times every time the timeoutchanges. Additionally, place a lower cap on synthetic build times, and allow this cap tobe controlled by the consensus. This should also improve the build time calculations,and should eliminate a case where Tor was allocating an excessive amount of temporary memory during timeout calculation. Bugs 1335 and 1245, bugfix on 0.2.2.2-alpha.

• Minor bugfixes:
– Eliminate a case where a circuit build time warning was displayed after network connectivity resumed.

• Minor features:
– Add a TIMEOUT_RATE keyword to the BUILDTIMEOUT_SET control port event, to give information on the current rate of circuit timeouts over our stored history.
– Add ability to disable circuit build time learning via consensus parameter and via a
LearnCircuitBuildTimeout config option. Also automatically disable circuit build time
calculation if we are either a AuthoritativeDirectory, or if we fail to write our state file.
Bug 1296.

Karsten web-enabled his ExoneraTor tool on the metrics website at http://metrics.
torproject.org/exonerator.html. ExoneraTor tells you whether there was a Tor relay running on a given IP address at a given time. Many legal advisors, lawyers, and law enforcement ask us for data regarding if a certain IP address hosted a Tor relay at a point in time. Now this data is easily available to all.

Karsten fixed stats on estimated user numbers after we broke the calculations of users from directory request sampling at select relays. We found that we can use entry-stats for better user number estimates.

Karsten compared descriptor tarballs collected by ernie with directory-archive script and found that we’re fine using ernie’s data. Ernie is the code that provides the data processing and backend for the metrics.torproject.org website.

Footprints from Tor Browser Bundle.

Erinn continues work on footprints of the Tor Browser Bundle for Linux and Apple OS X.

Translation work, ultimately a browser-based approach.

  • A new translator, pierre, translated the entire website, torbutton, and gettor email autoresponder into French.
  • Added pashto (Pakistani) to the portal by request.
  • Updated translations for the website, torbutton, orbot, tor, and tor manual pages for French, Spanish, Russian, Mandarin Chinese, Farsi, Italian, Arabic, Dutch, Serbian, Portugese, Danish, Japanese, Polish, and Turkish.

Comments

Please note that the comment area below has been archived.

July 13, 2010

Permalink

«we removed all 512 nodes from the network consensus»

Why is it called "consensus" if you can decide it!?!!!!!!! hahaha!!!!! this is funny!!!!!!!! It reminds me of Sarkozy's three strikes proposal!!!!!!!!

I ain't sure about this, but if it's possible to arbitrarily kick out network nodes, who controls the consensus controls the nodes too!!!!!!!!!!!! I did read something about directory authorities, and i feel like this is related!!, but i don't have yet got what they're useful for, nor how they do work!!!!!! It just seems me strange the TorProject is able to disconnect hundreds of nodes all at once!!!!!!!! How does it work?!!!!!!!!

~bee!!!!!

July 13, 2010

Permalink

This "bee" person seems to really not get Tor at all. It makes me wonder why he's even here.

I think he's here to cause drama, he offers just enough useful info so some people think he is helpful, but IMO he is really a troll trying to cause trouble. He is rude, arrogant, and not the smart apparently as he makes incorrect assumptions about Tor operation and than makes wild conspiracy theory claims against Tor and Tor devs, he takes every opportunity to bash Tor and especially Tor Browser Bundle often calling it insecure and laughs at it, telling everyone how stupid they are and how smart he is, while spamming for his version of Tor Browser Bundle.

Bee needs to go away, I have been writing this for a while now.

July 14, 2010

Permalink

Why couldn't we use the 512 nodes?

Were they Bad Exits?

We could have used them atleast as entry/middle nodes?

It was Free Bandwidth for the Tor Network!

Hi!!!!!!!!!!!!

I think you're right!!! Removing those 500 nodes was a waste!!!!!!!!!!!! They were useful nodes!!! but i think the TorProject had no ways to take advantages of the suspected relays!!!!!!
Anyway, i know there is already a flags system to flag nodes!!! "BadExit" to disable exit-nodes and "BadDirectory" to disable directory caches!!!!! I even read of it, at phobos's suggested document!!!!
I think somebody could add a new flag, "BadNode"!!!!! yeah, it seems not to exist!!!! but i think it could be useful to have!!!!
A "BadNode" is a believed "suspected relay"!!!!!
Every node flagged as BadNode should be only used as a middle relay!!!! If you had 500 "suspected" nodes, and if they all were flagged as BadNodes, you couldn't use more than one of them at once!!!! Because if you've circuits made of three nodes and BadNodes cannot be used as entry/exit nodes, then you can only have a BadNode in the middle!!!!!!! Timing attacks aren't possible to launch from BadNodes, because a "BadNode" will never be used as an entry node, neither as an exit-node!!!!!! If you're very paranoid, for four hops circuits, you may want to add a rule to use only "one" BadNode per circuit!!! So, as you've got two nodes in the middle, only one of them can be a node flagged as "suspicious node"!!!!!!!
Yeah!!! An adversary who controls 500 or 5000 nodes could use them for timing attacks, but think about those 5000 nodes if they were fagged as in my idea of "BadNode"s!!!! instead of disabling them!!!! YEAH!! What do you think about this!!!!?!!!!!!!!!!!!?!!!!!!!!!
Hah yeah!!! i also know of "entry guards nodes" but i think my idea to be helpful to be used together!!!!!!!!

bye!!!!!!!!!!!!!!!!
~bee!!!!!!!!!!

July 14, 2010

Permalink

TOR dead in china now. Get new Bridge, ok couple days. Then blocked. even too much trouble for expert user, ordinary user no chance no way will make it work or want take all such big trouble. No matter if bridge from web or email they all already blocked. or blocked in few days time.

You saying here "Bridge relays that have been seeded into various social networks in China as well as new bridge addresses continue to work well" but never can having many users this way.

Read a minute the blogs, twitter, they all say same, TOR now finished in china, pay vpn now only solution.

GFW won. You having lost. Time to face reality and face facts.

This is the next step in the arms race between censors and circumvention tools. GFW appears to be 90% successful in blocking tor right now. We're working on the next steps to push that back to 0%. We don't want to roll out something that can be trivially blocked again. Therefore, it takes time to make the changes correctly. We only get one chance at it, and if we screw up, we may make the GFW admins job easier.

There's also a risk to using pay VPNs, see https://sedvblmbog.tudasnich.de/faq.html.en#Torisdifferent

The alternative answer is to encourage people to run bridges.

July 15, 2010

In reply to phobos

Permalink

Yes I know it is not your blame. Thank you for the hard working! WIsh you good lucky with one new TOR version! We all are your benefit from your hard working!

LOL "Face reality"......I'm sure Ghandi, Mandela, the Suffragettes, Rosa Parks, etc etc were all told that.....then look what happened. It's only 90% blocked, it can be unblocked especially if it's blocking IP address....you change them.

PS what's a Directory Fetch?

July 15, 2010

Permalink

Question: close to a month ago this problem popped up https://trac.torproject.org/projects/tor/ticket/1572
It still leaves Tor/Vidalia completely useless on my computer. I've been trying to find previous vidalia bundles for Mac OSX but all I've been able to find on the website are older versions of Tor on it's own. I know there are fine folks working on the problem in that ticket (and doing the best they can with limited resources) but if you could link to somewhere I could find the previous vidalia bundle, that would be wonderful.

archive.torproject.org is what you're looking for.

However, updating the ticket with more information may help.

I can't replicate any of the issues you're having.

You could try to compile polipo yourself and see if it still has problems.

July 16, 2010

Permalink

Tor was working fine on my xp sp2 a few days ago. after that,i uninstalled firefox. now i've reinstalled it and tor just doesn't connects to the network. It is stuck at the 'Loading Network Status' in the progress bar. In the message log it shows that my clock is not configured correctly, and until it does, it won't start. Why the clock is important? Am i supposed to keep adjusting the time (not to mention calculating around 80,000 secs into exact minutes everytime) and it still doesn't do a thing. For some reason i can't even optimize my clock from microsoft site. What should i do?

July 18, 2010

Permalink

Why is Tor so hard to install on Ubuntu?

In windows, I download one app (Vidalia), and everything works great.

On ubuntu, I have to enter a bunch of commands into the command prompt, manually configure files, and I have no visibility to what's going on... what the hell!?

We pulled tor and vidalia out of the Ubuntu repositories because Ubuntu shipped a remotely exploitable tor for 18 months and refused to update it. Therefore, we host our own repositories to keep everyone current with Tor and vidalia releases.

You could use the tor browser bundle for linux to avoid any installation issues, see https://torproject.org/torbrowser/

July 19, 2010

In reply to phobos

Permalink

Oh, that is available for linux too? Nice. You should update the download page, as it only references a browser bundle for Windows.

Hi!!!!!!!!!!!!!

I also made a Tor Browser Bundle for Linux!!!!! It's FactorBee!!!!!!!!!! http://honeybeenet.altervista.org/factorbee/ in the screenshot page, there is also a pic of factorbee running in Ubuntu!!!!!!!!! haha yeah!!!!!!!!! It's similar to the official tor browser bundle belonging to the TorProject, but my one is better!!!!!! This is the support forum if you need to ask something: http://honeybeenet.altervista.org/forum/?board=factorbee !!!!!!

If you've a 32 bit system, you can just download the precompiled version!!! but if you have a 64bit system, you must compile factorbee from the source code!!!!!! Because i don't have a precompiled 64bit version!!!! But if it's possible for you, download the source code and compile it either way!!!!!! When you've done and you've got the executable file, install EncFS (apt-get install encfs) and then, to use factorbee, just launch it from a terminal "./factorbee" (or also, with GNOME, doubleclick on the "factorbee" script and click on "Run"!!!!!!!!!).

FactorBee will give you some advantages over the official Tor Bundle!!!!! For example, all temporary files will be stored in the encrypted file system of EncFS and everything will be destroyed when the scripts terminate!!!!!!! This will prevent actual writings of plain-text files on your harddisk, but if you read the documentation you'll find more about factorbee!!!!!!!!! You could also write the files directly into the RAM memory instead of on the disk!!!!!!!! There is also a script to run firefox in a chroot!!!!! This is the comparison chart i wrote time ago http://honeybeenet.altervista.org/factorbee/?id=116000 it's a bit outdated already, because since then the official Tor Browser Bundle has improved pretty much!!!!!!!!!!!!!! (though factorbee still the number one!!!!!!!!!!!!!!!!!)

bye!!!!!!!!!!!!!
~bee!!!!!!!

July 20, 2010

Permalink

On June 2, updated the Vidalia bundle for OS X PowerPC to include Vidalia 0.2.9.

Only on unstable package?

August 10, 2010

Permalink

Weird - wonder if Tor is working properly: Max download speed via my ISP plan is close to 60KB/s. Previously, whenever using Tor (via Torbutton and Privoxy on Linux system), the download speed would max out at about 30 KB/s. Frequently however, with Tor running and verified at https://check.torproject.org/ and at http://ip-address.domaintools.com/, the max speed is ~60 KB/s - the maximum for my Internet plan. Is Tor working? Could it be as fast as the fastest non-Tor? Any way to check such as allowing Privoxy to log? --thanks anyone