The 2nd USENIX Workshop on Free and Open Communications on the Internet (FOCI '12) seeks to bring together researchers and practitioners from technology, law, and policy who are working on means to study, detect, or circumvent practices that inhibit free and open communications on the Internet.
The Internet offers great promise for improving the communication capabilities of citizens, but our increasing dependence on networked communications also makes it easier for organizations to control, monitor, and block communications. ISPs and governments routinely restrict access to Internet content and services, either by censoring access to information or by degrading the performance of services or blocking them entirely. Similarly, ISPs can degrade network performance for certain sets of users for some or all services, for arbitrary purposes. ISPs have been found to block or throttle certain application traffic routinely. This growing trend toward blocking, tampering, or otherwise restricting communications on the Internet calls for improved techniques both for monitoring the state of restrictions on Internet content and communications, in order to inform users, and for circumventing attempts to censor, degrade, or otherwise tamper with Internet communications.
The broadening scope of attacks on Internet freedom is forcing more disciplines to address the issue. Last year's workshop brought together four research communities:
- Those studying network neutrality and performance degradation
- Those measuring content censorship and blocking of resources and services
- Those designing and evaluating censorship circumvention tools
- Those who work on the wider implications of censorship, bringing perspectives from the worlds of policy, law, ethics, and political and social sciences
This second workshop aims to repeat and promote this critical interdisciplinary approach.
Six-page short-paper submissions are due April 26 (edit: May 3), and the workshop is August 6 near Seattle. See the full Call for Papers for details.
The Tor Browser Bundles have all been updated to the latest Firefox 11.0 as well as a number of bugfixes. Because of a very slow uplink, not all of the Mac OS X 64-bit bundles are available yet, but all of the 32-bit bundles are up, and the Farsi (sig) and English (sig) versions of the 64-bit bundles are also available.
Tor Browser Bundle (2.2.35-9), Linux only
- Fix launch script to prevent Vidalia from running in debug mode all the time (closes: #5417)
Tor Browser Bundle (2.2.35-8)
- Update Firefox to 11.0
- Update OpenSSL to 1.0.0h
- Update NoScript to 2.3.4
- Update HTTPS Everywhere to 2.0.1
- Always build to with warnings enabled (closes: #4470)
- Disable HTTPS Everywhere SSL Observatory screen (closes: #5300)
- Remove tor-resolve from the Windows bundle (closes: #5403)
Mac OS X
- Don't attempt to load the default KDE 4 theme from Vidalia, because that fails when the Qt versions don't match (closes: #5214)
Interested in coding on Tor and getting paid for it by Google? If you are a student, we have good news for you: We have been accepted as a mentoring organization for Google Summer of Code 2012 together with The Electronic Frontier Foundation! Woo!
Here are the facts: The summer of code gives you the opportunity to work on your own Tor-related coding project with one of the Tor developers as your mentor. You can apply for a coding project related to Tor itself or to one of its many supplemental projects (as well as for an EFF-related project). Your mentor will help you when you're stuck with your project and guide you in becoming part of the Tor community. Google pays you 5,000 USD for the three months of your project, so that you can focus on coding and don't have to worry about how to pay your bills.
Did we catch your attention? These are your next steps: Go look at the Google Summer of Code FAQ to make sure you are eligible to participate. Have a look at our ideas list to see if one of those projects matches your interests. If there is no project on that list that you'd want to work on, read the documentation on our website and make up your own project idea! Come to #tor-dev on OFTC and let us know about your project idea. Communication is essential to success in the summer of code, and we're unlikely to accept students we haven't heard from before reading their application. So really, come to the IRC channel and talk to us!
We are looking forward to discussing your project idea with you!
Although Tor was originally designed to enhance privacy, the network is increasingly being used to provide access to websites from countries where Internet connectivity is filtered. To better support this goal, Tor introduced the feature of bridge nodes – Tor nodes which route traffic but are not published in the list of available Tor nodes. Consequently bridges are commonly not blocked in countries where access to the public Tor nodes are (with the exception of China and Iran).
For bridge nodes to work well, we need lots of them. This is both to make it hard to block them all, and also to provide enough bandwidth capacity for all their users. To help achieve this goal, the Tor Browser Bundle now makes it as easy as clicking a button to turn a normal Tor client into a bridge. The upcoming version of Tor will even set up port forwarding on home routers (through UPnP and NAT-PMP) to make it easier still.
There are, however, potential risks to Tor users if they turn their client into a bridge. These were summarized in a paper by Jon McLachlan and Nicholas Hopper: "On the risks of serving whenever you surf". I discussed these risks in a previous blog post, along with ways to mitigate them. In this blog post I'll cover some initiatives the Tor project is working on (or considering), which could further reduce the risks.
The attack than McLachlan and Hopper propose involves finding a list of bridges, and then probing them over time. If the bridge responds at all, then we know that the bridge operator could be surfing the web though Tor. So, if the attacker suspects that a blogger is posting through Tor and the blogger's Tor client is also a bridge, then only the bridges which are running at the time a blog post was written could belong to the blogger. There are likely to be quite a few such bridges, but if the attack is repeated, the set of potential bridge IP addresses will be narrowed down.
What is more, the paper also proposes measuring how quickly each bridge responds, which might tell the attacker something about how heavily the bridge operator is using their Tor client. If the attacker probes the rest of the Tor network, and sees a node with performance patterns similar to the bridge being probed, then it is likely that there is a connection going through that node and that bridge. In some circumstances this attack could be used to track connections all the way through the Tor network, and back to a client who is also acting as a bridge.
One way of reducing the risk of these attacks succeeding is to run the bridge on a device which is always on. In this case, just because a bridge is running doesn't mean the operator is using Tor. Therefore less information is leaked to a potential attacker. As laptops become more prevalent, keeping a bridge on 24/7 can be inconvenient so the Tor Project is working on two bits of hardware (known as Torouters) which can be left running a bridge even if the user's computer is off. If someone probes the bridge now, they can't learn much about whether the operator is using Tor as a client, and so it leaks less information about what the user is doing.
Having an always-on bridge helps resist profiling based on when a client is on. However, evaluating the risk of profiling based on bridge performance is more complex. The reason this attack works is that when a node is congested, increasing traffic on one connection (say, due to the bridge operator using Tor) decreases the traffic on another (say, the attacker probing the bridge). If you run a Tor client on your PC, and a Tor bridge on a separate device, this reduces the opportunity for congestion on one leading to congestion on the other. However, there is still the possibility for congestion on the network connection which the bridge and device share, and maybe you do want to use the bridge device as a client too. So the Torouter helps, but doesn't fix the problem.
To fully decouple bridges from clients, they need to run on different hardware and networks. Here the Tor Cloud project is ideal – bridges run on Amazon's (or another cloud provider's) infrastructure so congestion on the bridge can't affect the Tor client running on your PC, or it's network.
But maybe you do want to use your bridge as a client for whatever reason. Recall that the first step of the attack proposed by McLachlan and Hopper is to find the bridges' IP addresses. This is becoming increasingly difficult as more bridges are being set up. Also, there is work in progress to make it harder to scan networks for bridges. Originally this was intended to make it harder to find and block bridges, but it applies equally well to preventing probing. These schemes (e.g. BridgeSPA by Smits et. al.) mean that just because you have a bridge's IP address, it doesn't mean that you can route traffic through it (to measure performance) or even check if the bridge is running. To do either, you need to have a secret which is distributed only to authorized users of the bridge.
There is still more work to be done in protecting bridge operators, but the projects discussed above (and in the previous blog post) certainly improve the situation. Work continues both in academia and at the Tor Project to better understand the problem and develop further fixes.
In February 2012 we learned that activists in Iran and Syria were targeted with two different types of malicious computer software. We received a copy of each malware, and Jonathan Tomek from ThreatGRID helped with the analysis.
How you get infected
The malicious software is spread as email attachments, and as files sent via Instant Messaging and Skype. The software looks like two completely harmless files; a Microsoft PowerPoint slide show and an image file. The malicious software will silently install itself on your computer when you open one of the files.
Malicious software, such as the two copies we analyzed, is normally designed to gather sensitive information and gain unauthorized access to a computer system. The seemingly harmless PowerPoint slide show turned out to be a keylogger, while the image file was really a backdoor, providing the attacker with full access to the system.
Both the keylogger and the backdoor will transfer data to www(dot)meroo(dot)no-ip(dot)org, on port 778. This domain name used to point to a server at a government-owned telecommunications company in Syria, but was later updated to point to a Linode server in London, UK. No-IP have since pointed the domain name to an invalid IP address (0.0.0.0).
Most anti-virus software will be able to detect and remove both the keylogger and the backdoor. You may try updating your anti-virus software, running it, and using it to remove the malware if anything pops up. However, the safest course of action is to re-install the operating system on your computer.
The EFF wrote a blog post called How to Find and Protect Yourself Against the Pro-Syrian-Government Malware on Your Computer. In the post, they recommend "that you take steps to protect yourself from being infected by not running any software received through e-mail, not installing software at all except over HTTPS, and not installing software from unfamiliar sources even if recommended by a pop-up ad or a casual recommendation from a friend.".
PowerPoint slide show: keylogger
When you first try to open the PowerPoint slide show, you will get a security warning asking if you really want to allow this file to run. The Name field points to the following executable file: C:\Program Files\Common Files\VMConvert32\wmccds.exe
If you ignore the warning and click Run, a self-extracting rar file will install the malware (the wmccds executable) onto your computer. The PowerPoint slide show will then open and you will see a series of images and some text in Farsi. The malware will not activate until you reboot your computer.
The first time you reboot, the malware will activate and start logging your keystrokes. If you are running Windows 7, you will see the same warning as mentioned above, and you have to click Run before the malware is actually activated. Older versions of Windows will not display this warning when you reboot.
The malware will modify the Windows startup script to ensure that the keylogger is always running when you are using the computer. The keylogger will affect your whole system, and it will even send the contents of your clipboard to the attacker. The Tor Browser Bundle does not protect you if you have a keylogger on your system.
Windows screen saver: backdoor
The Windows screen saver contains a type of malware that is a bit more complex than the one described above. When you run the Windows screen saver, it will start an image program and show you a picture (we saw a picture of a rifle, but that is not always the case). Meanwhile, the malicious software installs a backdoor onto your computer and opens a connection to www(dot)meroo(dot)no-ip(dot)org, using port 778.
The backdoor (1122333.exe in the Documents and Settings folder), which is similar to the DarkComet Remote Administration Tool, allows the attacker to connect to your computer and do anything that he or she wants, including logging keystrokes and acting as the system administrator. The malware will modify the Windows startup script to ensure that the connection is always open.
A number of good blog posts have been written about how you can avoid risk, protect your online identity, blog safely and so on. We decided to collect links to some of these posts so that you can easily find the information most relevant to you.
How to Blog Safely (About Work or Anything Else) is a guide written by the EFF. The guide talks about how you can use Tor to blog anonymously, and offers a few simple precautions to help you maintain control of your privacy.
Blog Stalkers – Personal Safety for Bloggers is a post written by Darren Rowse. The blog post tells the story of how Rowse had to deal with a stalker for some time, and lists some things to consider regarding the information you reveal online about yourself and your family.
Anonymous Blogging with WordPress & Tor is a guide written by Ethan Zuckerman for Global Voices Advocacy. The guide walks you through how you can use Tor, WordPress and various free email accounts to blog anonymously.
Defending Privacy at the U.S. Border: A Guide for Travelers Carrying Digital Devices is a guide by the EFF. The guide explains why your devices can be searched at the border, how the U.S. Government searches devices, and gives advice on how to protect your data.
HTTPS Everywhere is a Firefox and Chrome extension that encrypts your communications with many major websites, making your browsing more secure. HTTPS Everywhere is a produced as a collaboration between The Tor Project and the EFF.
Safety tips on blogging from Microsoft. This short guide lists some basic guidelines for bloggers, and also gives some advice to parents about how they can talk to their kids about the Internet and blogging.
The Tor network relies on volunteers to donate bandwidth. The more people who run Tor as a bridge or a relay, the faster and safer the network becomes. Tactical Tech created a video to encourage you to join the Tor Network. The video, and information about how you can set up a bridge or a relay, can be found on https://www.torproject.org/relays. If you want to help us translate the video into your language, let us know!
The full HD video can be found here: https://media.torproject.org/video/2012-03-04-BuildingBridges-HD.ogv
There are new alpha Tor Browser Bundles and Vidalia Bundles available for testing!
These bundles include the latest Vidalia 0.3.1 alpha release and Tor 0.2.3.12-alpha.
Right now they are technology previews, so they aren't on the main download page yet, but please try them out and give us feedback in our bug tracker.
Mac OS X
There are also normal Vidalia bundles available for Windows and 32-bit non-ppc OS X (10.5 and up) here:
Mac OS X