[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-talk] Roger's status report, Oct 2012

1) I attended WPES and the first day of CCS:
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"
    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:
  - "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.

    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"
    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:

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:

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:

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:
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
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.

- 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.

- Released Tor
- Released Tor
- Released Tor
including writing up the Tor 0.2.3 Release Notes:
- Released Tor

tor-talk mailing list