I spent two days in Iceland discussing Tor and freedom of information with various people. I talked to a few people, including a member of Icelandic Parliament, about the International Modern Media Institute, http://immi.is/. The goals of IMMI are to secure free speech and defining new operating principles for the global media. They are starting with Iceland and moving on to the world. They already have much success in Iceland, but are running into issues of scale and funding. They could use some help.
The second day I talked to the computer forensics team from the National Police of Iceland about Tor, http://www.logreglan.is/. We discussed all things Tor and their experiences with it. Apparently there are 'computer specialists' traveling Europe talking to law enforcement (for great profit) disparaging any technology that provides security and privacy to citizens as 'for child abuse and organized crime'. These people neglect to mention that all technologies are dual usage and the human behind it determines the good or bad usage of the technology. One of the officers mentions that no one talks about crowbar crime, but everyone is talking about computer crime as if humans aren't involved. Overall, it was a great discussion lasting a few hours.
I then head over to work with the people from 1984, https://1984.is/. They are one of the largest hosting providers in Iceland. And thanks to them, we now have http://torproject.is hosted in the country. I learned more about the physical infrastructure of the Internet in Iceland. We discussed ways to increase competition now that the Iceland Govt bailed out the company that owns nearly all of the fiber in the country. Imagine a country with fiber everywhere (already true in Iceland) and treating it like the road infrastructure with any provider getting access to it. Now mix in successful freedom of expression laws from IMMI.
That night I talked about Tor to the only hackerspace in Iceland at their beer and crypto night at Hakkavélin, http://hakkavelin.is/. Someone showed up and recorded my entire talk until their battery ran out. kapteinnkrokur posted the video at https://www.youtube.com/watch?v=pOayRK48vdE. I covered Tor topics, life under surveillance, and some more advanced topics relating to bridges, ssl filtering, and attempted DHT directory info over Tor. Afterwards, many went out to a bar to talk more until 2 AM. I had a great chat with Bjarni and Ewelina from PageKite, https://pagekite.net/, about Tor marketing, supporting privacy enhancing technology, and peer to peer collaboration for all.
Iceland is a fantastic country and the people are great. I hope to spend more time there, as soon as the volcanoes stop disrupting flights.
Thank you to Björgvin, Birgitta, Berglind, and Mörður for arranging meetings and hosting me for the two days.
Thanks to everyone for attending today. We had some great discussions about The Haven Project, Economic Association for tor relay operators, telecomix, pluggable transports, TAILS, IPv6, sandboxing flash, and of course, tor itself.
And a great bit of gratitude to iis.se for promoting and hosting the hackfest, and for providing food. https://www.iis.se/blogg/hackare-intar-se and the followup, https://www.iis.se/internet-for-alla/reportage/teknikreportage/hackare-i...
We need more bridges. When I first envisioned the bridge address arms race, I said "We need to get lots of bridges, so the adversary can't learn them all." That was the wrong statement to make. In retrospect, the correct statement was: "We need the rate of new bridge addresses to exceed the rate that the adversary can block them."
For background, bridge relays (aka bridges) are Tor relays that aren't listed in the main Tor directory. So even if an attacker blocks all the public relays, they still need to block all these "private" or "dark" relays too. We deployed them several years ago in anticipation of the upcoming arms race, and they worked great in their first showing in 2009. But since then, China has learned and blocked most of the bridges we give out through public (https and gmail) distribution channels.
One piece of the puzzle is smarter bridge distribution mechanisms (plus see this post for more thoughts) — right now we're getting 8000 mails a day from gmail asking for bridges from a pool of less than a thousand. The distribution strategy that works best right now is ad hoc distribution via social connections. But even if we come up with brilliant new distribution mechanisms, we simply need more addresses to work with. How can we get them? Here are five strategies.
Approach one: Make it easy to become a bridge using the Vidalia interface. This approach was our first try at getting more bridges: click on "Sharing", then "Help censored users reach the Tor network". Easy to do, and lots of people have done it. But lots here is thousands, not hundreds of thousands. Nobody knows that they should click it or why.
Approach two: Bridge-by-default bundles. People who want to help out can now simply download and run our bridge-by-default bundle, and poof they're a bridge. There's a lot of flexibility here. For example, we could provide a customized bridge-by-default bundle for a Chinese human rights NGO that publishes your bridge address directly to them; then they give out the bridge addresses from their volunteers through their own social network. I think this strategy will be most effective when combined with targeted advocacy, that is, after a given community is convinced that they want to help and want to know how they can best help.
Approach three: Fast, stable, reachable Tor clients auto-promote themselves. Tor clients can monitor their own stability, performance, and reachability, and the best clients can opt to become bridges automatically. We can tune the thresholds ("how fast, how stable") in the directory consensus, to tailor how many clients promote themselves in response to demand. Read the proposal for more details. In theory this approach could provide us with many tens of thousands of bridges in a wide array of locations — and we're drawing from a pool of people who already have other reasons to download Tor. Downsides include a) there's quite a bit of coding work remaining before we can launch it, b) there are certainly situations where we shouldn't turn a Tor user into a bridge, which means we need to sort out some smart way to interact with the user and get permission, and c) these users don't actually change addresses as often as we might want, so we're still in the "gets lots of bridges" mindset rather than the "increase the rate of new bridge addresses" mindset.
Approach four: Redirect entire address blocks into the Tor network. There's no reason the bridge and its address need to run in the same location, and it's really addresses that are the critical resource here. If we get our friends at various ISPs to redirect some spare /16 networks our way, we'd have a lot more addresses to play with, and more importantly, we can control the churn of these addresses. Past experience with some censors shows that they work hard to unblock addresses that are no longer acting as proxies. If we light up only a tiny fraction of the IP space at a time, how long until they block all of it? How much does the presence of other services on the address block make them hesitate? I want to find out. The end game here is for Comcast to give us a few random IP addresses from each of their /24 networks. All the code on the Tor bridge side already works here, so the next steps are a) figure out how to teach an ISP's router to redirect some of its address space to us, and then b) sign up some people who have a good social network of users who need bridges, and get them to play that arms race more actively.
Approach five: More generic proxies. Originally I had thought that the extra layer of encryption and authentication from a bridge was a crucial piece of keeping the user (call her Alice) safe. But I'm increasingly thinking that the security properties she gets from a Tor circuit (anonymity/privacy) can be separated from the security properties she gets from the bridge (reachability, and optionally obfuscation). That is, as long as Alice can fetch the signed Tor network consensus and verify the keys of each of the public relays in her path, it doesn't matter so much that the bridge gets to see her traffic. Attacks by the bridge are no more effective than attacks by a local network adversary, which by design is not much. Now, this conclusion is premature — adding a bridge into the picture means there's a new observation point in addition to the local network adversary, and observation points are exactly what the attacker needs to correlate traffic flows and break Tor's anonymity, But on the flip side, right now bridges already get to act as these observational points, and the extra layer of encryption they add doesn't seem to help Alice any. So it's too early to say that a socks or https proxy is just as safe as a bridge (assuming you use a full Tor circuit in either case), but I'm optimistic that these more generic proxies have a role to play.
If we go this route, then rather than needing volunteers to run a whole Tor (which is especially cumbersome because it needs libraries like OpenSSL), people could run socks proxies on a much broader set of platforms. For example, they should be easy to add into Orbot (our Tor package for Android) or into Seattle (an overlay network by UW researchers that restricts applications to a safe subset of Python). We could even imagine setting up a website where volunteers visit a given page and it runs a Flash or Java applet socks proxy, lending their address to the bridge pool while their browser is open. There are some gotchas to work through, such as a) needing to sign the applets so they have the required network permissions, b) figuring out how to get around the fact that it seems hard to allow connections from the Internet to a flash plugin, and c) needing to program the socks proxy with a Tor bridge or relay address so the user doesn't have to ask for it (after all, socks handshakes are unencrypted and it wouldn't do to let the adversary watch Alice ask for an IP address that's known to be associated with Tor). This 'flash proxy' idea was developed in collaboration with Dan Boneh at Stanford, and they are currently designing and building it — stay tuned.
A visual history of our website, as seen through svn code commits, from the beginning.
The full movie is at https://media.torproject.org/video/tor-website-history-movie.mpg or after the jump.
The April 2011 Progress Report is attached to this post and available at https://blog.torproject.org/files/2011-April-Monthly-Report.pdf.
Highlights include releases for tor, vidalia, arm, and libevent. Updates to pluggable transports, obfsproxy, torbutton, many translation and core architecture updates.
Just some quick links to what interests us over the past week.
- In DHS Takedown Frenzy, Mozilla Refuses to Delete MafiaaFire Add-On, http://wendy.seltzer.org/blog/archives/2011/05/05/in-dhs-takedown-frenzy...
- Civic Disobedience and the Arab Spring, http://www.ethanzuckerman.com/blog/2011/05/06/civic-disobedience-and-the...
- Tor Servers bombarded with bittorrent DMCA Notices, http://torrentfreak.com/tor-servers-bombarded-with-bittorrent-dmca-notic...
- Shirley Hung on control of the Chinese Internet, http://www.ethanzuckerman.com/blog/2011/05/06/shirley-hung-on-control-of...
- What Syria’s Unblocking of Facebook Was Really About, http://jilliancyork.com/2011/05/06/what-syrias-unblocking-of-facebook-wa...
- A Syrian Man-In-The-Middle Attack against Facebook, https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook
We're pleased to announce that the Tor Project, Tails, and Guardian are hosting students this year as part of Google Summer of Code. Out of the 31 applications to us we were able to take on six fantastic students:
Julien Voisin - Introduction
Project: Metadata Anonymisation Toolkit
Mentor: Mike Perry
George Kadianakis - Introduction
Project: Pluggable transports
Mentor: Nick Mathewson
Sathya Gunasekaran - Introduction
Project: Orbot + ORLib
Mentor: Nathan Freitas
Kamran Khan - Introduction
Project: GTK+ Frontend and Client Mode Improvements for arm
Mentor: Damian Johnson
Max - Introduction
Project: Custom GDM3 startup menu, aka. tails-greeter
Project: Blocking-resistant Transport Evaluation Framework
Mentor: Thomas Benjamin
Projects officially begin on May 23rd. We're thrilled to have them with us, and have our fingers crossed that they'll stay afterward to become core developers.
Many thanks to Google for having the program again this year! -Damian
The alpha Vidalia bundles have also been updated with the latest Torbutton 1.3.3-alpha which has itself been updated to work with the latest Firefox 4.0.1 release and has this notable feature:
When used with Firefox 4 or the alpha Tor Browser Bundles, it also
features support for youtube videos in HTML5, but you must currently
opt-in for youtube to provide you with HTML5 video as opposed to
Tor Browser Bundle changelogs follow.
Firefox 3.6 Tor Browser Bundles
Tor Browser Bundle for Windows
1.3.24: Released 2011-04-30
- Update Firefox to 3.6.17
- Update Libevent to 2.0.10-stable
- Update zlib to 1.2.5
- Update OpenSSL to 1.0.0d
Tor Browser Bundle for Linux
1.1.8: Released 2011-04-30
- Update Tor to 0.2.2.25-alpha
- Update Firefox to 3.6.17
Tor Browser Bundle for OS X
1.0.16: Released 2011-04-30
- Update Tor to 0.2.2.25-alpha
- Update Firefox to 3.6.17
Firefox 4 Tor Browser Bundles
Tor Browser Bundle (2.2.25-1) alpha; suite=all
- Update Tor to 0.2.2.25-alpha
- Update Firefox to 4.0.1
- Update Torbutton to 1.3.3-alpha
- Update BetterPrivacy to 1.50
- Update NoScript to 188.8.131.52
Temporary direct download links for Firefox 4 bundles: