The Tor Browser Bundles have all been updated to the latest Firefox (10.0) as well as a number of other software version updates.

https://www.torproject.org/download

Tor Browser Bundle (2.2.35-5)

• Update Firefox to 10.0
• Update Qt to 4.7.4
• Update OpenSSL to 1.0.0g
• Update zlib to 1.2.6
• Update HTTPS Everywhere to 1.2.2
• Update NoScript to 2.2.8
• New Firefox patches
• Limit the number of fonts per document

Linux changes

• Put documentation in remove-shared-lib-symlinks debug dumps (closes: #4984)

Windows changes

• Make sure mozconfig always gets copied into the Firefox build directory
  (closes: #4879)

The right to read is a fictional story but it warns of a future that has already started to arrive; it paints a picture where information is controlled with a heavy hand and simply reading, let alone speaking is an extremely dangerous activity. In the words of William Gibson, "The future is already here — it's just not very evenly distributed". Restrictions on the right to read though the Internet perfectly match this observation. A lot should be said about perceptions of censorship, and it is often thought that places like Syria or Iran are unique. Generally, people in the West hold that those countries obviously censor as is consistent with facts of life in a supposedly non-free country. This probably holds a lot of truth but it absolutely fails to address the core of the issue — these countries and those networks are not unique.

In fact, we find uncensored networks to almost be an abnormal state. The so-called free countries in the West often shape and tamper with network traffic. They often also log data and even collaborate with governments. Generally, people don't see evidence of this and as a result, they often perceive that their Internet connections aren't monitored or censored. These days are quickly coming to an end and while it sounds like hyperbole, here are examples in the United Kingdom and in the United States of America.

Recently it has come to our attention that our primary website is filtered by Vodafone in the UK, by 3 (three.co.uk) in the UK, by O2 in the UK, and by T-Mobile in the UK and the USA. It used to be the case that we only saw filtering and censorship events in places like Egypt, Syria, or Iran and now we're going to explore what those attacks look like in the context of the UK and the USA.

When a visitor uses a pre-paid account on the T-Mobile USA network and attempts to visit http://www.torproject.org/, they are redirected to a block page. This is enabled by default without user's affirmative consent and only savvy privileged users may even attempt to disable this censorship. There is an informational page about the T-Mobile censorship system and it explains that this censorship may be disabled. We've heard reports that attempts to disable the censorship are not always successful and this certainly doesn't bode well for an easy and censorship-free Internet experience.

The T-Mobile USA network censorship appears to be simple to bypass: it appears to only trigger when a client sends Host: torproject.org on TCP port 80 and visitors that use HTTPS will probably not notice or be obviously impacted by their censorship.

This kind of censorship raises all kinds of interesting questions. I suspect it raises US legal and social questions as well. The Tor Project is a registered 501c3 non-profit corporation in the state of Massachusetts, and the block was experienced in California. Does this count as interfering with interstate commerce? What duty of care does T-Mobile USA have when it relies on systems or infrastructure funded by the public? What duty of care do they have as a common carrier?

Similarly, when a user on the UK Vodafone network visits http://www.torproject.org/ they are greeted by a block page as well. You can visit this block page without directly using their networks. Detecting their filters is straightforward and we see tampering at the sixth hop.

Here is a tcptraceroute to TCP port 80 of torproject.org from an Ubuntu machine connected to the Internet via Vodafone UK:

Tracing the path to www.torproject.org (86.59.30.36) on TCP port 80 (www), 30 hops max
1 192.168.1.1 2.379 ms 1.011 ms 1.313 ms
2 10.252.225.61 90.998 ms 133.672 ms 95.963 ms
3 10.252.224.186 78.865 ms 91.722 ms 91.415 ms
4 * * *
5 10.203.64.130 88.502 ms 73.259 ms 80.765 ms
6 www.torproject.org (86.59.30.36) [open] 77.927 ms 152.599 ms 96.399 ms


Here is a normal traceroute to torproject.org from an Ubuntu machine connected to the internet via Vodafone UK:

traceroute to www.torproject.org (86.59.30.36), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 9.669 ms 9.583 ms 9.460 ms
2 10.252.225.61 (10.252.225.61) 98.084 ms 98.046 ms 98.224 ms
3 10.252.224.219 (10.252.224.219) 98.760 ms 109.326 ms 109.261 ms
4 host203.msm.che.vodafone (10.203.64.154) 109.087 ms 127.554 ms 127.426 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 85.205.0.110 (85.205.0.110) 180.920 ms 180.692 ms 180.652 ms
10 85.205.0.109 (85.205.0.109) 180.659 ms 180.473 ms *
11 85.205.116.5 (85.205.116.5) 260.480 ms * 85.205.116.1 (85.205.116.1) 152.107 ms
12 92.79.213.157 (92.79.213.157) 152.265 ms 152.099 ms 151.808 ms
13 92.79.209.210 (92.79.209.210) 151.453 ms 151.124 ms 92.79.203.254 (92.79.203.254) 151.129 ms
14 vin-145-254-19-130.arcor-ip.net (145.254.19.130) 157.978 ms vin-145-254-19-126.arcor-ip.net (145.254.19.126) 119.699 ms 129.820 ms
15 te3-1-vix-iec-c2.ix.sil.at (193.203.0.6) 129.999 ms 136.314 ms 136.338 ms
16 86.59.118.145 (86.59.118.145) 136.033 ms 135.826 ms 135.666 ms
17 www.torproject.org (86.59.30.36) 151.282 ms 118.185 ms 114.603 ms


We've additionally found that pre-paid T-Mobile UK accounts also experience censorship that is similar to T-Mobile USA. Detection of their filter is possible with some of the techniques that I've demonstrated, and it is quite trivial to see that TCP port 80 and 443 are treated in a special way.

Here is a tcptraceroute to TCP port 80 of torproject.org from an Ubuntu machine connected to the Internet via T-Mobile UK:

Tracing the path to torproject.org (38.229.72.14) on TCP port 80 (www), 30 hops max
1 * * *
2 10.126.241.49 305.721 ms 429.908 ms 449.875 ms
3 10.70.16.221 480.031 ms 339.890 ms 429.951 ms
4 10.70.17.87 480.447 ms 449.365 ms 439.979 ms
5 vescum.torproject.org (38.229.72.14) [open] 459.935 ms 659.964 ms 449.849 ms


Here is a tcptraceroute to TCP port 443 of torproject.org from an Ubuntu machine connected to the Internet via T-Mobile UK:

Tracing the path to torproject.org (86.59.30.36) on TCP port 443 (https), 30 hops max
1 * * *
2 10.126.241.53 357.474 ms 360.016 ms 389.772 ms
3 10.70.16.217 490.136 ms 409.878 ms 359.945 ms
4 10.70.17.87 469.956 ms 489.883 ms 389.868 ms
5 www.torproject.org (86.59.30.36) 410.024 ms 420.494 ms 399.888 ms
6 10.70.17.66 389.470 ms 429.923 ms 339.861 ms
7 10.70.16.50 430.002 ms 349.850 ms 450.012 ms
8 10.70.17.103 339.900 ms 389.836 ms 390.031 ms
9 149.254.199.162 369.851 ms * 924.522 ms
10 10.126.168.218 420.035 ms 379.878 ms 409.968 ms
11 xe-1-3-2-19.lon10.ip4.tinet.net (77.67.73.209) 469.942 ms 480.002 ms 499.940 ms
12 xe-5-3-0.vie20.ip4.tinet.net (89.149.180.6) 399.851 ms 379.892 ms 379.929 ms
13 silver-server-gw.ip4.tinet.net (77.67.82.234) 419.899 ms 479.926 ms 449.923 ms
14 www.torproject.org (86.59.30.36) 389.925 ms 449.789 ms 549.993 ms
15 www.torproject.org (86.59.30.36) [open] 419.869 ms 469.997 ms 479.839 ms


Compare with a normal traceroute to torproject.org from an Ubuntu machine connected to the Internet via T-Mobile UK:

traceroute to torproject.org (38.229.72.14), 30 hops max, 60 byte packets
1 * * *
2 10.126.241.49 (10.126.241.49) 99.671 ms 99.856 ms 159.584 ms
3 10.70.16.221 (10.70.16.221) 179.672 ms 190.046 ms 159.760 ms
4 10.70.16.50 (10.70.16.50) 190.250 ms 179.356 ms 90.611 ms
5 10.70.17.103 (10.70.17.103) 90.565 ms 110.275 ms 90.508 ms
6 149.254.199.162 (149.254.199.162) 110.476 ms 110.449 ms 110.391 ms
7 10.126.168.214 (10.126.168.214) 70.022 ms 70.062 ms 60.303 ms
8 xe-1-3-2-19.lon10.ip4.tinet.net (77.67.73.209) 60.322 ms 69.380 ms 69.383 ms
9 * * *
10 limelight-lon-gw.ip4.tinet.net (213.200.77.118) 59.798 ms 60.535 ms 179.659 ms
11 tge11-1.fr4.lga.llnw.net (69.28.172.149) 240.999 ms 221.715 ms 221.191 ms
12 tge14-4.fr4.ord.llnw.net (69.28.189.53) 230.570 ms 229.966 ms 210.814 ms
13 tge7-1.fr3.ord.llnw.net (69.28.172.41) 210.575 ms 200.446 ms 199.453 ms
14 ve8.fr3.ord4.llnw.net (68.142.80.130) 169.521 ms 148.181 ms 168.037 ms
15 cymru.tge6-3.fr3.ord4.llnw.net (68.142.73.198) 248.264 ms 229.474 ms 249.066 ms
16 vescum.torproject.org (38.229.72.14) 249.289 ms 249.234 ms 259.448 ms


In the examples above we see that T-Mobile UK treats TCP port 80 in a special manner and effectively stops users from reaching our web site. This is an attack against users who attempt to connect to our infrastructure. This attack, while primitive, demonstrates an active and malicious action on the part of the above named Internet providers.

We've additionally seen reports of the UK O2 network blocking connections to http://www.torproject.org/ in exactly the same way that Vodafone UK blocks access. The O2 filter has been covered in the popular media in the recent past and we're sad to hear that they've decided to include Tor's website in their race to the bottom.

In all the above cases we do not see DNS tampering but rather outright Man-In-The-Middle attacks against connections to our web server. These censorship systems do not currently implement a Man-In-The-Middle attack against the SSL services offered by our web server. It is not much of a stretch of the imagination to think that such an action may be a future plan; we've seen it elsewhere.

Current users of the Tor network are not impacted by this filtering, but these networks are attempting to deny new users the ability to start using Tor without extensive efforts. You can view their filter page without using their service; the exact block page is also available externally. It appears that it is possible for users to disable this censorship by providing a credit card as a proof of age. This is not exactly a privacy-friendly tactic. The O2 Twitter account contacted me and said they were willing to review their censorship policy for torproject.org but they did not offer to remove the censorship entirely.

This trend of providing partially censored Internet in what we all think of as free countries is alarming. Are we supposed to look the other way because the mobile Internet isn't the same as the "real" Internet? Should we worry that Vodafone's capabilities and behavior here remind us of what they did in Egypt last year? It would seem that the war over network neutrality is far from won.

(Investigation and research thanks go to Andrew Lewman, Steven Murdoch and Runa Sandvik of the Tor Project, SiNA of RedTeam LLC, Jim Killock, Lee Maguire, Peter Bradwell of the Open Rights Group and their project blocked.org.uk and Richard Clayton from the University of Cambridge.)

The Tor Project doesn't usually get involved with U.S. copyright debates. But SOPA and PIPA (the House's "Stop Online Piracy Act" and the Senate's "Protect-IP Act") go beyond enforcement of copyright. These copyright bills would strain the infrastructure of the Internet, on which many free communications -- anonymous or identified -- depend. Originally, the bills proposed that so-called "rogue sites" should be blocked through the Internet's Domain Name System (DNS). That would have broken DNSSEC security and shared U.S. censorship tactics with those of China's "great firewall."

Now, while we hear that DNS-blocking is off the table, the bills remain threatening to the network of intermediaries who carry online speech. Most critically to Tor, SOPA contained a provision forbidding "circumvention" of court-ordered blocking that was written broadly enough that it could apply to Tor -- which helps its users to "circumvent" local-network censorship. Further, both bills broaden the reach of intermediary liability, to hold conduits and search engines liable for user-supplied infringement. The private rights of action and "safe harbors" could force or encourage providers to censor well beyond the current DMCA's "notice and takedown" provision (of which Chilling Effects documents numerous burdens and abuses).

On January 18, we're joining Wikipedia, Reddit, the MIT Media Lab, and hundreds of others in protest, turning a portion of the Tor site black to call attention to copyright balance and remind the US Congress and voters of the value of the open Internet.

U.S. citizens, please call or write, to urge your representatives to stop SOPA and PIPA. Elsewhere in the world, keep an eye out for similar legislation. and bring the fight there too.

The Tor Cloud images for all the seven regions have been updated to include the anonymizing relay monitor (arm). This works much like top does for system usage, providing real time statistics for bandwidth, cpu, memory usage, current Tor configuration, connection details etc.

If you're already running a Tor Cloud instance and wish to install arm, connect to your instance with SSH and run sudo aptitude install tor-arm.

Our progress report for December 2011 is available as a pdf with pretty graphs and text file. Highlights are on hidden services fixes, openssl fixes, obfuscating proxy progress, and general updates on advocacy and releases.

The Amnesic Incognito Live System (Tails), version 0.10, is out.

Changes

Notable user-visible changes include:

• Tor: upgrade to 0.2.2.35-1.
• Iceweasel
  • Install Iceweasel 9.0 from the Debian Mozilla team's APT repository.
  • Update Torbutton to 1.4.5.1-1.
  • Support viewing any YouTube video that is available in HTML5 format.
  • Use Scroogle (any languages) instead of Scroogle (English only) when booted in English. Many users choose English because their own language is not supported yet; let's not hide them search results in their own language.
  • Install the NoScript Firefox extension; configure it the same way as the TBB does.
  • Disable third-party cookies. They can be used to track users, which is bad. Besides, this is what TBB has been doing for years.
• Do not transparently proxy outgoing Internet connections through Tor. Instead drop all non-Torified Internet traffic. Hence applications has to be explicitly configured to use Tor in order to reach the Internet from now on.
• Software
  • Upgrade Vidalia to 0.2.15-1+tails1. This version will not warn about new Tor versions (this is handled by Tails security check instead).
  • Upgrade MAT to 0.2.2-1~bpo60+1.
  • Upgrade VirtualBox guest software to 4.1.6-dfsg-2~bpo60+1, built against the ABI of X.Org backports.
  • Upgrade I2P to 0.8.11; the start script (which was broken in Tails 0.9) is now fixed.
  • Install unar (The Unarchiver) instead of the non-free unrar.
  • Install Nautilus Wipe instead of custom Nautilus scripts.
• Hardware support
  • Upgrade Linux kernel to 3.1.6-1.
  • Upgrade to X.Org from squeeze-backports.
  • Install more, and more recent b43 firmwares.
  • Upgrade barry to 0.15-1.2~bpo60+1.
• Internationalization
  • Add basic language support for Russian, Farsi and Vietnamese.
  • Install some Indic fonts.
  • Install some Russian fonts.
  • Add Alt+Shift shortcut to switch keyboard layout.
• Miscellaneous
  • Support booting in "Windows XP-like camouflage mode".
  • Do not fetch APT translation files. Running apt-get update is heavy enough.
  • Add MSN support thanks to msn-pecan.
  • Add custom SSH client configuration:
    • Prefer strong ciphers and MACs.
    • Enable maximum compression level.
    • Explicitly disable X11 forwarding.
    • Connect as root by default, to prevent fingerprinting when username was not specified.
  • Replace flawed FireGPG with a home-made GnuPG encryption applet; install a feature-stripped FireGPG that redirects users to the documentation, and don't run Seahorse applet anymore.
  • Blank screen when lid is closed, rather than shutting down the system. The shutdown "feature" has caused data losses for too many people, it seems. There are many other ways a Tails system can be shut down in a hurry these days.
  • Fix bug in the Pidgin nick generation that resulted in the nick "XXX_NICK_XXX" once out of twenty.
  • Pre-configure the #tor IRC discussion channel in Pidgin.
  • Reintroduce the htpdate notification, telling users when it's safe to use Tor Hidden Services.
  • Various htpdate improvements.

Plus the usual bunch of minor bug reports and improvements.

See the online Changelog for technical details.

I want to try it / to upgrade!

See the Getting started page.

Known issue

The memory erasure on Tails shutdown cannot guarantee that all memory in the 2 GB to 4 GB region is wiped. The improvements made in Tails 0.10 should at least make the situation better than previously.

Getting good stories for Tor successes is tricky, because if Tor is doing its job, nobody notices. I know a lot of people who have really interesting Tor success stories and have no interest in telling the world who they are and how they managed (until that moment when everybody is reading about them, that is) to stay safe.

Still, there are a bunch of other stories out there that haven't been documented as well. For example, I really like Nasser's story about his experiences in Mauritania:
http://www.technologyreview.com/computing/22427/page4/

Hidden services have gotten less broad attention from the Tor user base, since most people who install Tor have a website in mind like twitter or indymedia that they want to visit safely. Some good use cases that we've seen for hidden services in particular include:

- I know people (for example, in countries that have been undergoing revolutions lately) who run popular blogs but their blogs kept getting knocked offline by state-sponsored jerks. The common blogging software they used (like Wordpress) couldn't stand up to the ddos attacks and breakins. The solution was to split the blog into a public side, which is static html and has no logins, and a private side for posting, which is only reachable over a Tor hidden service. Now their blog works again and they're reaching their audiences. And as a bonus, the nice fellow hosting the private side for them doesn't need to let people know where it is, and even if somebody figures it out, the nice fellow hosting it doesn't have any IP addresses to hand over or lose.

- Whistleblowing websites want to provide documents from a platform that is hard for upset corporations or governments to censor. See e.g. http://globaleaks.org/

- Google for 'indymedia fbi seize'. When Indymedia offers a hidden service version of their website, censoring organizations don't know which data centers to bully into handing over the hardware.

- Data retention laws in Europe (and soon in the US too at this rate) threaten to make centralized chat networks vulnerable to social network analysis (step one, collect all the data; step two, get broken into by corporations, criminals, external governments, you name it; step three comes identity theft, stalking, targeted scam jobs, etc etc). What if you had a chat network where all the users were on hidden services by default? Now there's no easy central point to learn who's talking to who and when. Building one and making it usable turns out to be hard. But good thing we have this versatile tool here as a building block.

That's a start. It is certainly the case that we (Tor) spend most of our time making the technology better, and not so much of our time figuring out how to market it and change the world's perception on whether being safe online is worthwhile. Please help. :)

You might also like
https://torproject.org/about/torusers.html.en
https://blog.torproject.org/blog/we-need-your-good-tor-stories

This blog post was adapted from an email to tor-talk by Roger. See the original email at https://lists.torproject.org/pipermail/tor-talk/2011-November/021997.htm...

Greetings! My name is Tim Wilde, Software Engineer at Team Cymru, Inc., and a big fan of the Tor Project and everything that they do. We've helped out the Tor Project with a few investigations into probing/blocking of Tor by oppressive regimes, and the guys asked me to write this one up for the Tor Blog, so here I am! Note: any opinions expressed here are mine, nor those of Team Cymru or the Tor Project.

In October 2011, ticket #4185 was filed in the Tor bug tracker by a user in China who found that their connections to US-based Tor bridge relays were being regularly cut off after a very short period of time. At the time we performed some basic experimentation and discovered that Chinese IPs (presumably at the behest of the Great Firewall of China, or GFW) would reach out to the US-based bridge and connect to it shortly after the Tor user in China connected, and, if successful, shortly thereafter the connection would be blocked by the GFW. There wasn't time for a detailed investigation and analysis at the time, but that kernel eventually grew into the investigation detailed below. We were, however, able to determine that limiting connections to the bridge relay to only the single IP expected to be its client would, in fact, block the probes and allow the connection to remain open for an extended period (>48 hours in our testing).

Between 05 DEC and 09 DEC 2011, we undertook a detailed and methodical investigation into probing and blocking of Tor connections originating within China. Unfortunately for our analysis, it appears that the GFW's active blocking of connections to Tor bridges had stopped, but we were still able to gather valuable data about the probing performed by the GFW, which previously led directly and verifiably to blocking.

To this end we discovered two types of probing. First, "garbage binary" probes, containing nothing more than arbitrary (but sometimes repeated in later probes) binary data, were experienced by the non-China side of any connection that originated from China to TCP port 443 (HTTPS) in which an SSL negotiation was performed. This probe was performed in near-real-time after the connection was established, implying near-line-rate deep packet inspection (DPI) capabilities. TCP/443 connections not performing an SSL handshake, such as using the obfsproxy obfs2 protocol or a plain-text protocol, did not provoke probing. The purpose of these probes is unknown, and further investigation is difficult to justify when it seems relatively clear that these probes are not aimed at Tor.

The second type of probe, on the other hand, is aimed quite directly at Tor. When a Tor client within China connected to a US-based bridge relay, we consistently found that at the next round 15 minute interval (HH:00, HH:15, HH:30, HH:45), the bridge relay would receive a probe from hosts within China that not only established a TCP connection, but performed an SSL negotiation, an SSL renegotiation, and then spoke the Tor protocol sufficiently to build a one-hop circuit and send a BEGIN_DIR cell. No matter what TCP port the bridge was listening on, once a Tor client from China connected, within 3 minutes of the next 15 minute interval we saw a series of probes including at least one connection speaking the Tor protocol.

The good news is, we were able to isolate which characteristic of the Tor handshake the GFW was using to decide whether or not to initiate these probes. By making a simple change to the list of supported SSL ciphers in the "hello" packet sent by the Tor client within China, we were able to prevent the probes from taking place. This has been documented and is being discussed in ticket #4744. This differs slightly from the method used by Iran to block Tor in September 2011, using the client-side of the SSL negotiation as its trigger rather than the server-side. It is likely, however, that technology capable of targeting either side of the connection to this degree could also target the other side, so it remains important to consider both the server and client sides of the Tor connection when attempting to blend in with normal, benign traffic.

The bad news, however, is that this is happening at all. This probe again implies sophisticated near-line-rate DPI technology, coupled with a system that is aimed directly at Tor, using code that actually speaks the Tor protocol. Clearly there is a target painted firmly on Tor, and it is quite likely that the Chinese will continue to adapt their censorship technology as the Tor Project adapts to them.

There is light at the end of the tunnel, though. A number of ideas have been put forward about new protocols, handshakes, and extensions to the Tor protocol that could be used to combat this type of censorship technology in a more long-term-sustainable way. Proposal 190 provides for password authorization for bridge relays. obfsproxy provides an extra layer on top of a Tor connection that makes it look like generic binary data. The Tor v3 link protocol/handshake, currently available and in testing in the 0.2.3.x-alpha series of Tor releases, eliminates SSL renegotiation in Tor session establishment, removing one of Tor's current "sore thumbs" that stick out from normal HTTPS SSL traffic.

You're welcome to check out my full report on this investigation for more detail than I could provide in the blog post here. Thanks very much to everyone who assisted with the investigation and the report! It was fun to investigate and report on this, and I hope to have the opportunity to help out with similar adventures in the future.