[tor-talk] Roger's status report, Oct 2012
Roger Dingledine
arma at mit.edu
Mon Dec 3 09:01:14 UTC 2012
1) I attended WPES and the first day of CCS:
http://hatswitch.org/wpes2012/
http://www.sigsac.org/ccs/CCS2012/
There are a bunch of new Tor-related research papers:
- "Changing of the Guards: A Framework for Understanding and Improving
Entry Guard Selection in Tor"
http://freehaven.net/anonbib/#wpes12-cogs
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"
http://freehaven.net/anonbib/#wpes12-torchestra
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"
http://freehaven.net/anonbib/#ccs2012-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"
http://freehaven.net/anonbib/#ccs2012-skypemorph
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"
http://freehaven.net/anonbib/#ccs2012-stegotorus
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"
http://freehaven.net/anonbib/#ccs2012-censorspoofer
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.
This recent variety of pluggable-transport designs and research
papers is great. 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.
- There's also "Touching from a Distance: Website Fingerprinting
Attacks and Defenses"
http://freehaven.net/anonbib/#ccs2012-fingerprinting
But I confess I haven't looked at it yet. Website fingerprinting
remains a huge and open issue that needs more attention.
2) Then 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:
http://www.scribd.com/doc/89690597/Willemsindictment-Filed-045
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 from Malaysia before
they switched to a Tor hidden service, and just the fact that Malaysia
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.
3) While there, I talked to some friends from MIT who now work on the
Akamai security team. I walked them through how they could usefully
contribute to Tor, and now they're running a pile of fast exit relays:
http://atlas.torproject.org/#search/akamai
4) From there, I went to DC for a week to participate in the SponsorF
"red team" event: they're funding some smart network security hackers to
evaluate Tor, obfsproxy, Stegotorus, etc and try to find holes in our
design and implementation.
They mostly ignored Tor, since it's gotten so much analysis and attention
from others in the research community. I wrote this list of attacks to
help convince them to focus on our other tools:
https://lists.torproject.org/pipermail/tor-dev/2012-September/003992.html
Useful outcomes included:
- https://trac.torproject.org/projects/tor/ticket/7190
- https://trac.torproject.org/projects/tor/ticket/7192
- https://trac.torproject.org/projects/tor/ticket/7211
- The realization that as the arms races continue, pluggable transport
designs will have to embed their messages inside the traffic generated
by the actual programs they're trying to imitate: e.g. we'll need
to ship a browser if we want our traffic to look like a browser
generated it. Anything else is a recipe for losing the arms race.
5) That week I finished hammering out the list of items that we're going
to promise for year3 of the grant:
https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorF/Year3
There are also a bunch of items we brainstormed that didn't make the final
list; hopefully those other items will make further censorship-research
funding proposals smoother.
6) From there, I went to UT Austin to do a talk for Vitaly Shmatikov's
research group. Nikita Borisov's grad student, Amir Houmansadr,
is post-docing with Vitaly, and they're working on interesting
pluggable-transport-related research. More details when their papers
get accepted.
Other things I did in October:
- Helped plan for some extra funding from SponsorJ, which
resulted in new tasks 10-13 at the end of the list on
https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorJ
We're going to need to hire some more browser hackers at this rate.
- Put out the blurb for the Flashproxy position, and helped David Fifield
look at some candidates. The result is that we're now paying Alexandre
Allaire to work on Flashproxy. Woo! And we could in theory pay some more
people if the perfect people show up.
https://www.torproject.org/about/jobs-pluggabletransport.html.en
- Put out the blurb for our Project Coordinator position. Helped to
interview some candidates, but we have many more to interview. It seems
we could really use a project coordinator to help us coordinate the
process of hiring a project coordinator.
https://www.torproject.org/about/jobs-projectcoordinator.html.en
- Released Tor 0.2.3.23-rc:
https://lists.torproject.org/pipermail/tor-talk/2012-October/026100.html
- Released Tor 0.2.4.4-alpha:
https://lists.torproject.org/pipermail/tor-talk/2012-October/026139.html
- Released Tor 0.2.3.24-rc:
https://lists.torproject.org/pipermail/tor-talk/2012-October/026184.html
including writing up the Tor 0.2.3 Release Notes:
https://gitweb.torproject.org/tor.git/blob/release-0.2.3:/ReleaseNotes
- Released Tor 0.2.4.5-alpha:
https://lists.torproject.org/pipermail/tor-talk/2012-October/026185.html
More information about the tor-talk
mailing list