tor browser bundle

Tor Browser Bundle 1.2.10 Released

phobos — Fri, 20 Nov 2009 20:43:26 -0800

On November 20, we released an updated Tor Browser Bundle, version 1.2.10, which includes:

updated Vidalia to 0.2.6
updated Pidgin to 2.6.3
updated Tor to 0.2.1.20
updated Firefox to 3.0.15
updated OpenSSL to 0.9.8l
updated libevent to 1.4.13

You can download the updated version at https://www.torproject.org/torbrowser/

Installing and using Tor

phobos — Thu, 19 Nov 2009 18:31:30 -0800

Thanks to Rob at Freedom House for putting together some videos about how to get, install, and use Tor, Tor Browser Bundle, and Bridges.

Installing and Using Tor, http://tinyvid.tv/show/3lejztnthk2tm
Installing and Using the Tor Browser Bundle, http://tinyvid.tv/show/b0e2hzylie8r
Installing and Using Bridges with Tor, http://tinyvid.tv/show/3uiwckrlqynqv

Freedom House has put together other videos on various tools to use to stay secure online at, http://www.youtube.com/freedom4internet.

Check them out and leave constructive feedback. I'm sure Rob will appreciate help with translating these videos as well.

Tor Browser Bundle 1.2.9 Released

phobos — Fri, 11 Sep 2009 18:55:03 -0700

Tor Browser Bundle 1.2.9 is released today. It updates Firefox and Pidgin Instant Messaging client to address the security issues in the older versions, and includes the latest and greatest Vidalia.

TBB can be downloaded from https://www.torproject.org/torbrowser.

The details of the changes are:

update Vidalia to 0.2.4
update Qt to 4.5.2
update Pidgin to 2.6.2
update Firefox to 3.0.14

Tor Browser Bundle 1.2.8 released

phobos — Wed, 19 Aug 2009 20:43:12 -0700

Tor Browser Bundle 1.2.8 is released. The big changes are the inclusion of statically linked openssl dlls to resolve a few geoip lookup and functionality issues with Vidalia, and the upgrade to the new Vidalia 0.2.2.

Available at https://torproject.org/torbrowser

The full list of updates and fixes:

update Torbutton to 1.2.2
update Vidalia to 0.2.2
compile OpenSSL 0.9.8k with Visual C to make dlls
update Pidgin to 2.6.1

Investigating http proxy performance with Tor

phobos — Wed, 19 Aug 2009 14:57:17 -0700

A while ago there was a thread on OR-TALK that devolved into

"why does Tor still ship ancient privoxy?"

and

"why are you shipping polipo with the Tor Browser Bundle instead of current privoxy?"

For those interested, the thread is here, http://archives.seul.org/or/talk/Jul-2009/msg00063.html.

Scott had a good argument for why we should update the bundles to the latest privoxy, and I agree, we should. But then I started thinking about why we needed a proxy at all. Almost all browsers support socks5 direct, isn't that faster than a middleman proxy?

This got me thinking about why polipo is in the TBB, but not the other packages. The TBB "feels faster" when using Tor than using the installed Tor, Vidalia, and Privoxy. However, I couldn't find any actual testing of performance of polipo vs. privoxy vs. socks5 direct.

So I did it myself, in a loose manner. I wanted to quantify "feels faster".

The raw data from all the testing is :

Tamper Data as xml,
proxy config files,
and results in a spreadsheet.

This is all contained in http://freehaven.net/~phobos/polipo-v-privoxy.tar.gz {.asc). There is a README as well. And yes, the ruby script is a quick and dirty hack.

I tested a few scenarios:

1) native polipo and privoxy without using Tor.
2) polipo and privoxy forwarding to Tor localhost:9050.
3) firefox socks5 direct to Tor via localhost:9050.

The summary of results:

Native polipo is 54.5% faster on average than native privoxy. This could be due to polipo's caching, http 1.1 pipelining, and it can serve bits as fast as they come in from the network. Privoxy needs to load the whole page, scan it, and then send it to the client. Even if privoxy filtering is disabled, it still works the same way.
Polipo caching shines with Tor usage. Performance is still about 40% faster with polipo than privoxy. Common images are cached, and served from the memory cache in single-digit millisecond ranges. Privoxy needs to wait for Tor to wholly deliver the bits. Caching is faster, this we know already. However, from a user perspective, it's just faster to load pages.
socks5 in Firefox 3.5.2 did better than I expected. It was about twice as slow as polipo, but still twice as fast as privoxy. I chalk this up to the tor circuit variability more than anything else.
I tried testing a click to a second page to see how much polipo caching helps people reading different pages on the same site. It helps, but not as much as I expected. Polipo ranged from slower than privoxy to 40-100% faster. Too much variability to make a real determination.

Caveats: Testing under tor is highly variable. I used the same circuits for both the polipo and privoxy tests to minimize variability. However, I can't control node load and congestion.

Out of 23 get requests for the Torproject.org/index.html.en, 17 are for the country flags. Perhaps we should load these last at the bottom of the page, or do something else to speed up the torproject page load.

As I was doing this, I kept thinking of other ways to do it better;

time requests and bits between tor, the http proxy, and the browser. How long does each request take to get from the browser, to the proxy, to tor and back across each layer? how much latency does each piece of software add to the request and delivery?
automate testing and let it run on a normal tor client over weeks. This will average out tor network variability and show "typical" user experience.
Pick a sampling of the top 100 websites by visits worldwide and measure their performance with the three methods, fully instrumented as in #1.
Do user experience measurements. Pay/ask/bribe people to sit in front of a computer, video record their browsing and feedback, and ask for a rating of each configuration (socks5, polipo, privoxy, and a placebo).
re-run #2 and run gcov to watch the code paths used in each piece of software, and figure out what can be optimized for performance.
test various "private browsing modes" through tor to see which browser is faster; firefox, safari, chromium, torfox, or torora.
how can we better tune polipo caching dynamically based on system ram config? Does having 1GB of cache provide significant benefits over the default?

I'm sure there are lots of things wrong with my measurements, minimal analysis, and results.

Constructive criticism is welcome.

Testing Tor Browser Bundle 1.2.7-dev

phobos — Sat, 15 Aug 2009 20:33:34 -0700

I've updated the Tor Browser Bundle with torbutton 1.2.2, the new Vidalia 0.2.2, and openssl 0.9.8k compiled with Microsoft Visual C to handle ssl compatibility issues with various versions of Windows.

If this works, it will be the new Tor Browser Bundle 1.2.8. Please test away.

The full list of changes:

update Torbutton to 1.2.2
update Vidalia to 0.2.2
compile OpenSSL 0.9.8k with Visual C to make dlls

There is an issue for some people using a clean Windows XP, Vista, 7 which would either require we ship the Visual C redistributable package, or compile OpenSSL ourselves with Visual C. The symptoms were the "find bridges now" button didn't appear in Vidalia 0.2.x, and the relays would never get flags. A few people posted comments to this blog about lacking flags and geoip information with TBB.

This is now fixed (at least it works on a freshly installed and patched WinXP system).

July 2009 Progress Report

phobos — Mon, 10 Aug 2009 01:07:57 -0700

New releases

On July 8th, we released Vidalia 0.1.15..

On July 8th, we updated the Tor 0.2.0.35-stable bundles with the new Vidalia to fix an ssl issue and the Firefox Torbutton extension installation for OS X users.

On July 8th, we released Tor 0.2.1.17-rc.

Tor Browser Bundle 1.2.3 was released on July 8, 2009.
TBB 1.2.3 was replaced by 1.2.4 on July 11, 2009
TBB 1.2.5 was released on July 25th. It solely included an update to Tor 0.2.1.18 .
TBB 1.2.6 was released on July 28th. It solely included an update to Tor 0.2.1.19.

On July 24th, we released Tor 0.2.1.18.

On July 28th, we released Tor 0.2.1.19.

Make Tor a better tool for users in censored countries

Tor 0.2.1.18 is our new stable. That is, this is the first stable release
of the 0.2.1.x branch. The 0.2.0.x branch went stable in July of 2008.
From the 0.2.1.18 release:

If the bridge config line doesn't specify a port, assume 443.
This makes bridge lines a bit smaller and easier for users to
understand.

If we're using bridges and our network goes away, be more willing
to forgive our bridges and try again when we get an application
request.

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

Proposal 166 details four steps we're taking to safely collect data
about Tor's network performance and network usage: 1) directory client
counts by country, 2) entry guard client counts by country, 3) relay
cell statistics, and 4) exit traffic by port and volume.
https://git.torproject.org/checkout/tor/master/doc/spec/proposals/166-st...

Hide Tor's network signature

Part of the reason why Tor might be especially slow in Iran could
be that they're doing deep packet inspection (DPI) to throttle SSL
connections. Tor's strategy of looking like SSL might turn out to be a
bad move in this case. It's hard to tell whether the SSL throttling is
actually happening, of course, because we get plenty of mixed information
from our sources in Iran. But if it *is* happening, we should start
investigating traffic obfuscation approaches that a) don't look like SSL,
but b) don't look recognizably like any other protocol.

Some other Iran circumvention developers have come up with a patch to
obfuscate ssh traffic:
http://github.com/brl/obfuscated-openssh/tree/master
http://c-skills.blogspot.com/2008/12/sshv2-trickery.html

Sometime soon we should start looking at designs to super-encrypt the
Tor link traffic in this way.

Grow the Tor network and user base. Outreach

On July 1st, Andrew gave a detailed Tor talk at the National Cyber Forensics and Training Alliance. Andrew's blog about the event is at https://blog.torproject.org/blog/visit-ncfta.

On July 7th, Andrew was a panelist for the CIMA/NED discussion on Iran and the Role of New Media, http://cima.ned.org/events/new-media-in-iran.html. Andrew's blog about the event is at https://blog.torproject.org/blog/cimaned-panel-iran-and-new-media.

On July 15th, Andrew presented Tor at Webinno22, http://www.webinnovatorsgroup.com/2009/07/06/the-webinno22-demo-companie.... Further discussions about online privacy startups and business deals with various investors and their seed companies are continuing since this event.

More press interviews and articles:

Iran activists work to elude crackdown on Internet, http://www.google.com/hostednews/ap/article/ALeqM5hTf-p6Iy3sWHK8BRR58npG...

http://blog.taragana.com/n/iran-government-builds-internet-walls-but-act...

Twitter and Facebook Help Protestors Connect, http://www.outloud.com/2009/issue96/protest.html

US set to hike aid aimed at Iranians, http://www.boston.com/news/nation/washington/articles/2009/07/26/us_to_i...

Senate OKs funds to thwart Iran Web censors , http://www.washingtontimes.com/news/2009/jul/26/senate-help-iran-dodge-i...

We wrote a follow-up blog post about the number of people using Tor
from Iran and China in June:
https://blog.torproject.org/blog/measuring-tor-and-iran-part-two

On July 1-5, Roger, Jake, Mike, and Damian attended Toorcamp in rural
Washington State. Roger did a talk on current attacks and vulnerabilities
in Tor.
http://www.toorcamp.org/content/B4

On July 21-23, Roger attended a workshop in DC at the National Academy of
Sciences. The workshop focused on the combination of Usability, Privacy,
and Security, and where future funding should concentrate.

On July 31, Roger gave a Defcon talk on the current state of Tor's
performance challenges and how we're addressing them:
http://defcon.org/html/defcon-17/dc-17-speakers.html#Dingledine
http://freehaven.net/~arma/slides-dc09.pdf

Preconfigured privacy (circumvention) bundles for USB or LiveCD.

Upgraded many programs in Incognito to address security concerns and general bugfixes.

Bridges

Updated geoip database. From the 0.2.1.18 release:

If the bridge config line doesn't specify a port, assume 443.
This makes bridge lines a bit smaller and easier for users to
understand.

If we're using bridges and our network goes away, be more willing
to forgive our bridges and try again when we get an application
request.

Scalability, load balancing, directory overhead, efficiency.

From the 0.2.1.18 release:
Network status consensus documents and votes now contain bandwidth
information for each relay. Clients use the bandwidth values
in the consensus, rather than the bandwidth values in each
relay descriptor. This approach opens the door to more accurate
bandwidth estimates once the directory authorities start doing
active measurements. Implements part of proposal 141.

When building a consensus, do not include routers that are down.
This cuts down 30% to 40% on consensus size. Implements proposal
138.

Authorities now vote for the Stable flag for any router whose
weighted mean time between failure (MTBF) is at least 5 days, regardless of the mean MTBF.

The main 2009 remaining performance changes are, in order of importance:
- Get the bwauthority scripts into place so authorities are voting on
more accurate bandwidths.
- Write a proposal for capping the circuit window much lower, and
implement it, and backport it to 0.2.1.x.
- Proposal 151: Mike's plan to track circuit build times and give up on
the slow ones.
- Write a proposal for refilling our bandwidth buckets intra-second.
Consider deploying in 0.2.2.x.
- Figure out what we can do for a less fair round-robin between active
circuits. My intuition is heading towards "we don't know what effect
each possible change will make, and our other changes are going to
have big effects, so we shouldn't deploy anything here quite yet."
- Get enough authorities upgraded that our bug 969 fixes ("voting wrong
on wfu and mtbf") take effect.

More reliable (e.g. split) download mechanism.

We have a new Volunteer, Jon, working on maintaining and expanding the list of tor mirrors. Jon has contacted all mirror maintainers and updated the mirrors list. Three were removed, two added, and seven updated with new information. There are 39 active mirrors.

Translations

10 Polish website updates
7 French website updates
1 Chinese website updates
German torbutton translations updated
Finnish torbutton translations updated
Generate translation infrastructure for our email auto-responder.
Ukrainian torbutton translation started
Start of a Thai torbutton translation
Spanish torbutton translation
Ukrainian check.torproject.org translation
Thai check.torproject.org translation

Our Google Summer of Code student, Runa, created a set of scripts to allow translators to translate our website content through the translation web portal. This will greatly simplify the process used to translate the website.

Tor Browser Bundle 1.2.7 Released

phobos — Thu, 06 Aug 2009 08:12:42 -0700

Tor Browser Bundle 1.2.7 is released. It is updated primarily due to Firefox 3.0.13 with its ssl fixes.

The full changelist is:

1.2.7: Released 2009-08-04

update Firefox to 3.0.13
add Polish translation
update libevent to 1.4.12

Tor Browser Bundle 1.2.5 and 1.2.6 released

phobos — Wed, 05 Aug 2009 23:51:22 -0700

Tor Browser Bundle 1.2.5 and 1.2.6 are released.

The changes for the respective releases are:

1.2.5: Released 2009-07-25
update Tor to 0.2.1.18

1.2.6: Released 2009-07-28
update Tor to 0.2.1.19

Tor Browser Bundle 1.2.3 and 1.2.4 Released

phobos — Sun, 12 Jul 2009 20:50:41 -0700

Tor Browser Bundle 1.2.3 was released on July 8, 2009. It contains the following changes:

Update Vidalia to 0.1.14
Update Tor to 0.2.1.17-rc
Update Pidgin to 2.5.8

TBB 1.2.3 was replaced by 1.2.4 on July 11, 2009 to include:

Include libeay32.dll from OpenSSL 0.9.8k to make QT happy
Update Vidalia to 0.1.15

TBB 1.2.4 is available at https://torproject.org/torbrowser.