In September, Karen and I attended a conference at the German Foreign Office to help
them decide what role Germany and the EU should have at regulating the sale of censorship and surveillance tools to dictators:
- I liked Eric King (from Privacy International)'s suggestion that when companies are submitting their tools for export evaluation, they should be required to submit their brochures too. Some of these companies are just shameless in terms of how they pitch their tool in terms of number of bloggers you can round up per unit time. He convinced me that controlling "the worst of the worst" in terms of how they can present their product will influence how these products spread.
- That said, these were all (foreign) policy experts, not technologists. They all seemed to take it for granted that you could draw a line between "bad" products and acceptable / dual-use products. I tried to hold back from saying "every time you people try to come up with legal phrasings about what technologies are ok, you end up putting tools like mine on the wrong side of the line." In retrospect, I should have said it more loudly.
- They were really proud to have Tor representatives there. Having us there let them show the world that they had "real technologists" at their meeting. There were several cases where the whole breakout session turned to me and wanted to know what Tor thought about the given question.
- I met a nice man who worked for a telco/DPI company that deploys its products in the Middle East. He raised a compelling argument: "Look, you folks are the ones that mandated backdoors in the telco equipment we produce, using the term 'lawful intercept'. And now you're surprised and upset when bad people use these same backdoors? You made us build it that way!" It certainly is easier for officials in countries like Germany to think of the world as divided between "good" places and "bad" places, but it sure isn't that simple.
Hi all. Just a friendly heads up concerning a couple things going on in our python controller space.
The first is that Mike and I have decided to deprecate TorCtl and make it a part of TorFlow (the framework used to support the Bandwidth Authorities and SoaT). The TorCtl codebase has largely been frozen for years out of concern for the stability of the Bandwidth Authorities (which lack any tests).
If you're writing scripts or controller applications for Tor then you're encouraged to move to either...
Library with a similar design to TorCtl, but friendlier APIs and documentation. This has reached feature parity with TorCtl and is still being actively developed, so if there's something it can do to better suit your needs then please let me know!
Twisted controller library written by Meejah, and used in projects like Ooni Probe.
Both of these libraries have extensive test suites and are being very actively maintained.
The second part are my plans regarding Stem. As of early December we've reached feature completion, covering just about everything in the control-spec and dir-spec.
Next up is migrating our controllers. So far we've moved arm (the largest python controller we have) and the consensus-tracker. Other controllers we have queued up to move are TorBEL, Tor Weather, and the control interpretor.
I've avoided making an initial release announcement for stem because until we have actual users of the library we won't be sure that we nailed a nice, intuitive API (and hence, can't promise that it'll be frozen).
On reflection this is letting the perfect be the enemy of the good. Stem's API is unlikely to change substantially, and holding off on an initial release poses a chicken-and-egg situation. Users want a frozen API before using stem, but we need users before feeling confident enough to lock down the API.
So here's what I propose. For the next couple months stem will have an open beta. If you'd like to have input on the future of our python controller space then please give Stem a try and tell me the following...
What pain points did you encounter? Is there anything that you'd like to see changed or that we're missing?
If your project is public then please tell me where I can find your code. I'll review it, both to suggest improvements and see how we can tweak stem to better suit your needs.
In the unlikely event we make a backward incompatible change I'll check with the beta participants to be sure we don't break anyone (and submit fixes if we do).
Cheers! -Damian (atagar on irc)
PS. Many thanks to Ravi, Sean, Eoin, Beck, Erik, Megan, Sathyanarayanan, and everyone else who has helped stem get to this point. Happy New Year!
Rob just tagged Shadow v1.6.1, and added a link on the download page. This is really more like a pre-1.7.0 release, but he wanted to get out some exciting new support for running multi-threaded simulations earlier!
This release includes:
- Support for running multi-threaded simulations! (use the “-w” flag to specify the number of worker threads)
- A few bugfixes
In preliminary testing, the biggest improvements have been seen when using between 4 and 8 worker threads. Happy simulating!
This January the Tor Project is supporting the Central America Domestic Violence Hackathon. The goal of this effort is to address the challenge of domestic violence by building technology solutions to assist agencies that work to support victims and advance efforts to bring perpetrators to justice.
This is being done by supporting communities on the ground in six Central America countries and Washington, DC. Already some of the organizations involved, including SecondMuse and the World Bank, have worked with these communities to define problems with potential for technical solutions. Next, these problems will be refined and then hacked on at a series of coordinated hackathons on January 26th and 27th, 2013.
We want to invite the Tor community to join us in this process. How can you help? There are two ways:
- Join the collaboration around defining strong problems. You can do this by reading the problem definitions and adding your comments, questions, and ideas. These problems have been generated primarily by non-technical organizations and your insight from a technical perspective can be invaluable. This includes feasibility, use cases, privacy and security concerns, existing solutions, and more.
- Join us on January 26th and 27th in one of the seven locations: Guatemala, El Salvador, Honduras, Nicaragua, Costa Rica, Panama, or Washington, DC.
We believe we can make a difference on domestic violence, and we need you.
Finally, if you'd like to get involved on a deeper level by organizing a problem refinement event, meeting with organizations in these locations, helping organize a hackathon, or more - contact the team running this project at firstname.lastname@example.org.
- "Changing of the Guards: A Framework for Understanding and Improving Entry Guard Selection in Tor". Basically Tariq has written a suite of tools for analyzing how likely an adversary is to be able to see a Tor user's circuits given various values for guard selection and guard rotation. Early results include "three guards is probably the wrong number" and "we probably shouldn't rotate guards so often". Later results I hope will include "here's an algorithm for assigning the Guard flag to relays that makes users safer".
- "Torchestra: Reducing interactive traffic delays over Tor". This paper suggests having two parallel TLS connections between each pair of relays — one for the loud circuits and one for the quiet ones. I've had a series of debates with Rob Jansen over whether this should really help, or if it's just shifting the round-robining to a deeper level (e.g. kernel-level buffers). My current opinion is that it should really help, not because it writes important bytes out faster, but because the other side can *read* important bytes faster — in the current state a relay can't predict which incoming bytes are going to be high-priority, but when high-priority bytes come on a separate TCP connection, it's easy to tell.
- "Enhancing Tor's Performance using Real-time Traffic Classification". I haven't read it in detail yet, but it looks at using machine learning to classify circuits depending on what sort of traffic they're carrying. This direction is worthwhile, but it skips over the question that Rob and I are currently wrestling with, which is "ok, so you've decided to give lower priority to a circuit. What should you actually do to make that circuit put less load on the network?" See also Rob's Usenix Security paper: http://freehaven.net/anonbib/#throttling-sec12
- "SkypeMorph: Protocol Obfuscation for Tor Bridges". The idea is to use the actual Skype program to make a (TCP) video call between user and bridge, and then drop the call and start up your own UDP traffic flows that mimic Skype's UDP flows in terms of size and timing. I'm not clear that trying to look like Skype is a game we can win (especially with DPI-level adversaries already playing the arms race to detect and block 'real' Skype, and with the wasted bandwidth that comes with pretending to be a Skype video call), but I think we can get a lot of mileage out of a Tor pluggable transport that carries Tor traffic over a UDP flow — especially with recent rumors of a Syrian ISP throttling all TCP flows.
- "StegoTorus: A Camouflage Proxy for the Tor Anonymity System". Stegotorus is an obfsproxy fork with two goals: first, chop up Tor traffic flows so you can't recognize Tor traffic just by looking for more 586-byte TCP packets than usual; and second, transport those chopped-up flows over a variety of steg modules, to hide the traffic in protocols that the adversary is unwilling to block (as opposed to obfsproxy's goal, which is to make a flow that's hard enough to DPI for that the adversary has to choose between blocking all unrecognized protocols or letting the flows through). Unfortunately, there aren't any great steg modules yet; rather, it aims to be a framework where if you *did* have a great steg module, you could just pop it in.
- "CensorSpoofer: Asymmetric Communication using IP Spoofing for Censorship-Resistant Web Browsing". It's designed for censored users who mostly consume bytes rather than produce them. This design also uses a UDP stream to deliver the bytes, but they spoof the stream as coming from a plausible-looking voip client rather than from the real source. Then they need some low-latency low-bandwidth way (e.g. instant messaging) to get the upstream packets to the server.
- There's also "Touching from a Distance: Website Fingerprinting Attacks and Defenses". But I confess I haven't looked at it yet. Website fingerprinting remains a huge and open issue that needs more attention.
This recent variety of pluggable-transport designs and research papers is fantastic. It also makes me realize that somebody should put some effort into identifying the various components that a Tor transport system needs, and which papers provide which components. For example, it sounds like SkypeMorph and CensorSpoofer could share the same details for the link encryption and flow control for their UDP stream, rather than inventing two separately. Similarly, the "small upstream channel" requirement from CensorSpoofer reminds me of the similar goal that David's Flashproxy design faces. I see that Tariq and Ian have a new tech report out that gives that a start.
In October I attended an FBI conference, as part of my work to try to keep Tor on good relations with law enforcement. My first goal is to remind them of all the good uses of Tor, so if they ever find themselves lobbying to outlaw anonymity online, they'll understand what they're giving up. The second goal is to make sure they understand what Tor is and how it works, so if they encounter it in their investigations they'll hassle our exit relay operators less. (Here's a great way that one FBI person explained it to me: "I've got 10 leads, and 48 hours before this case doesn't matter anymore. If you can help me understand which leads *not* to follow, I can do my job better.") My third goal is to help them be able to use Tor correctly for their own jobs — remember that diversity of users is part of what makes Tor safe for everybody to use.
Overall, we've been doing a pretty good job at teaching US-based law enforcement about Tor. At the end of the conference, one of the FBI agents took me aside and asked "surely you have *some* sort of way of tracking your users?" When I pointed at various of his FBI colleagues in the room who had told me they use Tor every day for their work, and asked if he'd be comfortable if we had a way of tracing *them*, I think he got it.
I met a nice man from the DEA who worked on the "Farmer's Market" bust. This was in the news a lot back in April, where apparently some people were selling drugs online, and using a Tor hidden service for their website. At the time I thought the news stories could be summarized simply as "idiot drug sellers accept paypal payments, get busted." It turns out they were pretty smart about how to accept paypal payments — they just had random Americans receive the paypal payments, take a cut, and then turn them into a Panama-based digital currency, and the Panama company didn't want to help trace where the money went. The better summary for the news stories should actually have been "idiot drug sellers use hushmail, get busted." Way before they switched to a Tor hidden service, the two main people used Hushmail to communicate. After a subpoena (and apparently a lot of patience since Canada still isn't quite the same as the US), Hushmail rolled over and gave up copies of all the emails. Many more details here:
I should still note that Tor doesn't introduce any magic new silver bullet that causes criminals to be uncatchable when before they weren't. The Farmer's Market people ran their webserver in some other foreign country before they switched to a Tor hidden service, and just the fact that the country didn't want to cooperate in busting them was enough to make that a dead end. Jurisdictional arbitrage is alive and well in the world.
The UK parliamentary committee considering the Draft Communications Data Bill, to which I gave evidence on behalf of The Tor Project, has now published their report (PDF version). The committee is highly critical of the draft bill, and calls for the government to consult technical experts, industry, law enforcement bodies, public authorities and civil liberties groups before re-drafting the proposed legislation. The committee's recommendations for this revised bill are summarised in section 8 of the report.
Tor is not explicitly dealt with by the report other than noting that systems that use encryption, including Tor, will pose a problem (paragraph 99) for proposals to ask communications service providers to record third party's data traversing their network. The report does however address numerous points which were raised in The Tor Project's written and oral evidence (and other organisation's submissions), including the over-broad powers the bill would hand over, the sensitivity of “communications data”, limited oversight, the challenge of storing sensitive data securely, and the rather dubious cost/benefit justification.
The committee has now completed its duties, and has consequently disbanded. The committee's report will now be considered by the government and we will be very interested in their response.
Testing versions of Tor Browser Bundle which include the alpha branch of the core Tor technology, version 0.2.4.6, are available directly from our archive at https://archive.torproject.org/tor-package-archive/torbrowser/tor-browse...
Tor 0.2.4.6 represents a volatile, testing branch of Tor for new and experimental features. A change log is available.
This is a very experimental version, please test and provide feedback at https://bugs.torproject.org.