February 2010 Progress Report

New releases

  • On February 13, we released a new stable version of Tor, 0.2.1.23. Tor 0.2.1.23 fixes a huge client-side performance bug, makes Tor work again on the latest OS X, and updates the location of a directory authority.
  • On February 21st, we released an update Tor stable in 0.2.1.24. Tor 0.2.1.24 makes Tor work again on the latest OS X – this time for sure!
  • On February 22, we released the latest in the -alpha series, 0.2.2.9-alpha.
  • On February 15th, we released an updated Tor Browser Bundle; version 1.3.2.
  • On February 27th, we released an updated Tor Browser Bundle, version 1.3.3.
  • On February 18th, Tor for the Nokia Maemo mobile platform was announced. https://blog.torproject.org/blog/tor-nokia-n900-maemo-gsm-telephone.
  • On February 7th, volunteers released a new beta of the Amnesia LiveCD, version 0.4.2. Amnesia is the merging of two projects, one of which is the Incognito LiveCD.

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

Work continues to improve the Tor ports for Android, Maemo, and iPhone.

We worked with Ian Goldberg at University of Waterloo to come up with a plan for one of his grad students to continue working on “Nymbler”, which is a framework they’re working on that will allow Tor users to remain anonymous yet prove to websites like Wikipedia and Slashdot that they are not jerks (or at least, not yet known to be jerks). This anonymous authentication approach will hopefully be a step toward letting Tor users post to Wikipedia again; but it is still in its very early stages.

Along these same lines, the Freenode IRC channel has been experimenting with a new way to allow Tor users to interact in their chat rooms while still being able to contain the abuse potential: http://blog.freenode.net/2010/01/connecting-to-freenode-using-tor-sasl/.

Architecture and technical design docs for Tor enhancements related to blocking-resistance.

Roger, Karsten, Steven met with Paul Syverson and Aaron Johnson at UT Austin to continue basic research on designs to let Tor users take advantage of local knowledge of how safe various Tor relays are in order to build safer paths through the network. The first goal is to answer questions like “If I believe that these relays are monitored by the Chinese government, then avoiding them will improve my security, but avoiding them could also stand out because I behave differently than other Tor users; what’s the right balance?” The second goal is to figure out how path selection should work when the user runs one of the relays herself, and thus knows it’s more trusted. The third goal is to come up with intuitive interfaces for letting users specify which parts of the network they trust more, while at the same time explaining the security implications of each choice.

Roger and Karsten also met with Vitaly Shmatikov to learn more about his recent work on “differential privacy”, which is an academic approach to making sure that numbers in databases do not leak too much identifying information. This question needs more attention because of the way Tor is computing and publishing “sanitized” user statistics on its metrics portal.

Roger also finished the first draft of his “Ten things to look for in tools that circumvent Internet censorship” document that we hope will eventually be a useful primer for policy people getting involved in this space: https://svn.torproject.org/svn/projects/articles/circumvention-features…

Grow the Tor network and user base. Outreach.

  • Roger spoke to the Philadelphia Linux Users’ Group about Tor and censorship. Several of the members are now looking at volunteering on Tor development. Roger also did a talk on Tor for undergraduates in Drexel University’s security class.
  • Andrew joined EDRI, http://www.edri.org, in a discussion with Members of European Parliament. and their staff along with senior staff from the European Commission Directorate-General - Justice, Freedom, Security about censorship, data retention, and online privacy.
  • Andrew gave a Tor talk to around 500 people at FOSDEM, http://www.fosdem.org.
  • Andrew, Roger, and Karen met with Access, http://accessnow.org, to discuss a bridges4tor campaign to increase the number of Tor Bridges, https://www.torproject.org/bridges, for users in censored countries.
  • Steven spoke to around 80 people at Secure Application Development 2010, http://secappdev.org/, in Groot Begijnhof, Leuven, Belgium.
  • We worked with Susan Landau to help her better understand Tor in the context of freedom, privacy, and circumvention tools, so that her upcoming book on the subject can be more accurate.
  • We worked with Dave Dittrich and other researchers in the botnet community to investigate a set of suspicious Tor relays that appeared to be associated with a bot network the researchers were tracking. We eventually decided to cut these suspicious relays out of the Tor network.
  • We talked a little bit with the fellow writing a circumvention tool called Puff. On the one hand, it looks like yet another centralized proxy where the operator could screw the users but promises not to. On the other hand, he seems technically savvy and he seems to really care about doing the right thing. We should talk with him more to help him improve the safety that his service can provide.

Bridge relay and bridge authority work.
We’re currently researching how to turn every tor client into a bridge by default, if the client finds itself reachable externally. This will dramatically increase the available bridges. There are some new attacks and challenges to overcome before this can be deployed as part of a -stable release, but we expect by Q3 2010 to have this into -alpha releases.

Scalability, load balancing, directory overhead, efficiency.
From the 0.2.2.9-alpha changelog:

We were selecting our guards uniformly at random, and then weighting which of our guards we’d use uniformly at random. This imbalance meant that Tor clients were severely limited on throughput (and probably latency too) by the first hop in their circuit. Now we select guards weighted by currently advertised bandwidth. We also automatically discard guards picked using the old algorithm. Fixes bug 1217; bugfix on 0.2.1.3-alpha. Found by Mike Perry.

More reliable (e.g. split) download mechanism.
Enhanced the metrics portal with numbers from the get-tor email autoresponder, http://metrics.torproject.org/gettor-graphs.html.

Footprints from Tor Browser Bundle.
We’ve picked up the work towards a Tor Browser Bundle for OS X and Linux, and hope to have experimental bundles for at least one of those platforms ready in March. Soon after they’re ready for testing, we’ll want to start looking at how footprints from running the bundle differ on each platform.

Translation work, ultimately a browser-based approach.
Translated content updates for Torbutton, Tor Browser, Website, General Documentation, Vidalia interface, and TorCheck in Chinese, German, French, Italian, Dutch, Norwegian, Polish, Russian, Arabic, Farsi, Burmese, Spanish, Swedish, and Turkish.

Hi!!!
Well, my one is much better than theirs!!!! The official Tor Browser Bundle for Linux sucks!!!!! they just did a copy of the one they've made for Windows, without adding nothing of new!!!!!!!!!! They worked on it for 6 months to make a poor product!!!! I worked on it for only one month and i did something of much better!!!!!!!!!!! It's your turn to think what's the better `Browser Bundle', i think my one is the greatest!!!!!!!! if you try it, you'll understand why!!!!!!! ~bee!!!!!!!!!!!

k239

March 25, 2010

Permalink

Hi!!!!! I would be careful about using security software from just anywhere!!!!!! Because it could grab my credit card details and send them to someone in China!!!!!!

Hi!!!!!!!!!! your post is right after my one and this is why i'm thinking that you were addressing it to me!!!!!
Well, what you said is very right and i agree with it!!!!!! This is why i believe that you aren't one (hypocritical), WINDOWS or MAC OSX, user!!!!!!!!! Indeed you are a GNU/LINUX user, and you can try FactorBee too!!!!!! Factorbee is safe because it's open source!!!!!!! Look at the source-code and compile/build it yourself!!!!! along with the source-code, in the same bzip2 package, you'll find the build instructions!!!! bye!!!!! ~bee!!!!!!!!!!!!!

The proxy server is refusing connections

Firefox is configured to use a proxy server that is refusing connections.

* Check the proxy settings to make sure that they are correct.

* Contact your network administrator to make sure the proxy server is
working.

The above is what I get when using this.
Any help?

The proxy server is refusing connections

Firefox is configured to use a proxy server that is refusing connections.

* Check the proxy settings to make sure that they are correct.

* Contact your network administrator to make sure the proxy server is
working.

http://xqz3u5drneuzhaeo.onion/users/mytorideaz/

SUGGESTION: ALERT BRIDGE OPERATORS WHEN THEY ARE GETTING BLOCKED
The current bridge strategy focuses on the TOR-user communication of bridges, and is basically a rationing strategy on user's ability to find out bridges. It works but there's an inbuilt limit on its effectiveness: the adversary typically provides the end user's connection, so can always in principle find out bridges by monitoring traffic.

It would be nice to also try to address this at the bridge provider end. Specifically, can you warn a bridge provider that their bridge is likely being blocked in some locations?

You could add a notification mechanism so when there is evidence a bridge is being systematically blocked in any location, the bridge operator gets a popup warning. A significant fraction of bridge operators will be using ADSL connections where to get a new IP address all they need do is switch the modem off and on again, making the bridge useful again.

Two possibilities here:
*The bridge operator's TOR installation itself monitors the number of incoming connections, and when it notices a significant drop from a particular location, pops up an alert.
*A centralized service does the monitoring and informs the bridge operator's TOR installation, which alerts the user.

Is it possible? It would be a useful feature as it would mean that at least some bridges are very very hard to block, and would reduce the fraction of bridges that are dead at any one time. :)

I was going to post a similar suggestion recently when the new blocks arrived but thought I'd wait and see if the Tor team move towards making accessible Tor client users active as bridges by default. I think this might be the better way really. .......................................................................................................................
I agree with the problem though. Running a bridge here I only became aware of the blocks after implementing a particular system that monitors for particular conditions that arrive when a block occurs that I threw together after China initiated the late December blocks. I don't imagine many people would do this though so gather there could be a significant problem with bridge ops not ever becoming aware of restricted access to the service short of them noticing a bandwidth usage drop or something.
.......................................................................................................................
I'm hoping the Tor-users-default-to-bridge ideas pan out. I see a fair amount more activity of the bridge here recently so I'm guessing there might be a shortage of bridge capacity out there at the moment. Many more bridges sounds like a good answer to me.
.......................................................................................................................
Also, captcha is really hard... 1+1=???????????

Something like this is on the todo list. The idea is the bridge authorities will notice when a bridge is blocked in country X and stop giving it out to users of that country.

Hi Phobos, actually I don't think this is the same as what the other commenter and myself are suggesting. We're suggesting that bridge operators are informed asap when they're being blocked, so they can take action and change their IP (if they're able to, which many operators will be), thus bringing their bridge back into play. Your idea, although useful, will do nothing to stop a bridge operator continuing to run their bridge on a blocked IP address, possibly for weeks or months. The operator will not realize that the bridge is not making a useful contribution to the Tor community, which is a pity. The two ideas are complementary and it would be nice to see both implemented. *** http://xqz3u5drneuzhaeo.onion/users/mytorideaz/

Ok. Just because a bridge is blocked by China, doesn't mean it is useless the world over. People in other countries will greatly appreciate that a bridge is stable and exists over a long period of time.

I understand your point and wish and it needs some thought, design, and coding.

Not useless, no, but my experience has shown China peers to be by far the most prolific users of a bridge, maybe even up around 95% or more. If as has happened now you find many bridges blocked, say 50%, then the remaining 50% would have to take the load of the ~95%. Better than nothing, and certainly better not to waste the China user's time with blocked bridge addresses, but not a great solution on it's own I don't think. I think it would be more ideal if bridge operators could be made aware of the situation in some way to allow for them to correct the problem short of there being a better solution (like many more bridges in general). *(I'm assuming here that bridge bandwidth capacity is actually an issue)*

De FOSDEM praten was geweldig. Andrew behandeld hecklers het vrij goed aan het eind. Ik waardeer de eerlijkheid van het Tor mensen als geheel. Ze lijken echt geloven in wat ze doen, ik hoop dat dit hen niet in de problemen komen.

Andrew bracht 10 minuten uitleg over de meest elementaire begrippen van Tor mij na het gesprek. Tannenbaum blies me met een antwoord op een woord en een blik van "jij idioot, niet mijn tijd verspillen." Echt geweldig om mensen die de zorg over gebruikers in de wereld, maakt niet uit hoe beroemd.

-De vraag meisje van FOSDEM

If google translate is accurate, I believe the correct answer is, you're welcome.

Murphy's law saved of all torizens.

Murphy's law was confirmed: the compensation of bugs of each other with an even numbers of those was happened. In conjunction of Tor and openssl, bug CVE-2010-0740 was compensated with lack of a proper mechanism of session's closure, SSL_shutdown() has not been used by Tor in practice at all.

Long live the score on the lack of specs and docs. SbO.

Great work, like always, thanks for all

SwissTorExit

my tor is not connecting its stopping at establishing network circuit.....i use MTN nigeria pls help hope MTN is not blocking me....kadex4real2002@yahoo.com

Thanks a lot. It works for me. I'm using it in Nigeria and it is damn fast. Hope you will send me the updates of the software at emtexonline@yahoo.com

Mine is working well.