Our progress report for January 2012 is available now. Highlights include two Tails releases, a summary of support calls for the past six months with actual user stories, a trip to Egypt for the 'Change your world' summit, updated metrics codebase, discussion of a new voting method, and lots of translation updates.
Available as a pdf with full color graphs, https://archive.torproject.org/monthly-report-archive/2012-January-Month...
or as a plain text file for portability and readability, https://archive.torproject.org/monthly-report-archive/2012-January-Month...
Over the past two days we've been hearing from, and working with, a number of Iranians having difficulty using Tor from inside Iran. It seems the Iranian government has ramped up censorship in three ways: deep packet inspection (dpi) of SSL traffic, selective blocking of IP Address and TCP port combinations, and some keyword filtering. For instance, they have partially blocked access to Tor's website, torproject.org, via IP address (such as 126.96.36.199) and port 443 (which is the HTTPS port). The third level of blocking is by keywords, such as searching for the word 'tor' via regular, non-encrypted search engine websites.
The blocks on SSL are not complete and not nationwide. Where blocking is in place, initial investigations show they are identifying the beginning of the SSL handshake and simply interrupting the handshake. We continue to research and investigate solutions with the assumption that SSL will eventually be blocked nationwide inside Iran. Our goal is to defeat their dpi signatures and allow tor to work by default.
The Iran Media Program has posted their thoughts on what is happening from a journalist's perspective.
So far, it seems the majority of Tor users are not affected by these blocks. Iran is still the #2 country based on direct usage, https://metrics.torproject.org/users.html?graph=direct-users&country=ir#.... This number is on the decline, however.
More details to follow as we have them.
Update 2011-02-10 18:05 UTC: We are working on making our obfuscating proxy more stable and easier to deploy. If you can compile code, following these directions will help. We're also working on Amazon EC2 instances of obfsproxy for point and click deployment.
The Tor Browser Bundles have all been updated to the latest Firefox (10.0) as well as a number of other software version updates.
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
- Put documentation in remove-shared-lib-symlinks debug dumps (closes: #4984)
- Make sure mozconfig always gets copied into the Firefox build directory
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 (188.8.131.52) 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 (184.108.40.206) [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 (220.127.116.11), 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 18.104.22.168 (22.214.171.124) 180.920 ms 180.692 ms 180.652 ms
10 126.96.36.199 (188.8.131.52) 180.659 ms 180.473 ms *
11 184.108.40.206 (220.127.116.11) 260.480 ms * 18.104.22.168 (22.214.171.124) 152.107 ms
12 126.96.36.199 (188.8.131.52) 152.265 ms 152.099 ms 151.808 ms
13 184.108.40.206 (220.127.116.11) 151.453 ms 151.124 ms 18.104.22.168 (22.214.171.124) 151.129 ms
14 vin-145-254-19-130.arcor-ip.net (126.96.36.199) 157.978 ms vin-145-254-19-126.arcor-ip.net (188.8.131.52) 119.699 ms 129.820 ms
15 te3-1-vix-iec-c2.ix.sil.at (184.108.40.206) 129.999 ms 136.314 ms 136.338 ms
16 220.127.116.11 (18.104.22.168) 136.033 ms 135.826 ms 135.666 ms
17 www.torproject.org (22.214.171.124) 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 (126.96.36.199) 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 (188.8.131.52) [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 (184.108.40.206) 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 (220.127.116.11) 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 18.104.22.168 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 (22.214.171.124) 469.942 ms 480.002 ms 499.940 ms
12 xe-5-3-0.vie20.ip4.tinet.net (126.96.36.199) 399.851 ms 379.892 ms 379.929 ms
13 silver-server-gw.ip4.tinet.net (188.8.131.52) 419.899 ms 479.926 ms 449.923 ms
14 www.torproject.org (184.108.40.206) 389.925 ms 449.789 ms 549.993 ms
15 www.torproject.org (220.127.116.11) [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 (18.104.22.168), 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 22.214.171.124 (126.96.36.199) 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 (188.8.131.52) 60.322 ms 69.380 ms 69.383 ms
9 * * *
10 limelight-lon-gw.ip4.tinet.net (184.108.40.206) 59.798 ms 60.535 ms 179.659 ms
11 tge11-1.fr4.lga.llnw.net (220.127.116.11) 240.999 ms 221.715 ms 221.191 ms
12 tge14-4.fr4.ord.llnw.net (18.104.22.168) 230.570 ms 229.966 ms 210.814 ms
13 tge7-1.fr3.ord.llnw.net (22.214.171.124) 210.575 ms 200.446 ms 199.453 ms
14 ve8.fr3.ord4.llnw.net (126.96.36.199) 169.521 ms 148.181 ms 168.037 ms
15 cymru.tge6-3.fr3.ord4.llnw.net (188.8.131.52) 248.264 ms 229.474 ms 249.066 ms
16 vescum.torproject.org (184.108.40.206) 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.
The Amnesic Incognito Live System (Tails), version 0.10, is out.
Notable user-visible changes include:
- Tor: upgrade to 0.2.2.35-1.
- Install Iceweasel 9.0 from the Debian Mozilla team's APT repository.
- Update Torbutton to 220.127.116.11-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.
- 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.
- 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.
- 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.
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.