Re: A few questions and potential answers:

[Roger Dingledine <arma@xxxxxxx>]

On Mon, Sep 20, 2010 at 03:22:57AM -0500, David Bennett wrote:
> Q: What is to stop operatives working for the bad guys from running
> tor proxies from 3rd party locations? Granted, they would only be able
> to sample a portion of the traffic, but traffic that they did sample
> could lead to identification of users.

Tor uses a distributed trust model, where any single relay doesn't get
to learn both the user and her destination. So yes, a bad guy can run a
relay, but the sample of network traffic he sees from that relay is not
useful to him. He needs to own multiple relays, and get lucky enough to
own the user's first hop and also her last hop. The math is a lot better
in that case, though still not perfect -- for c out of n proxies run by
the bad guy, the chance he wins is (c/n)^2 rather than c/n.

See
http://freehaven.net/anonbib/#onion-routing:pet2000

> It doesn't seem like it would
> be that hard to match up the encrypted client side requests with the
> un-encrypted outgoing requests.

Correct, it isn't hard.

> PA: The only solution I can think of here is centralized control of
> the proxy network provided by a press/media sponsorship model as
> opposed to the bandwidth volunteer model. It's to easy for bad guys to
> infiltrate the volunteer network.

If you're talking about a one-hop network (that is, a network where
users route through one proxy and then to their destination), then yes,
I think centralized control is a slightly better idea. But I think one-hop
proxies are a horrible idea for anonymity, whether centralized or not.

Aside from the "does the proxy want to learn about my browsing habits"
question, you need to wonder about whether the network itself (e.g. the
proxy's upstream) wants to track things.

See also Section 5 of
https://www.torproject.org/press/presskit/2010-09-16-circumvention-features.pdf

> It would also be easier to swap in
> and out new proxies as they are blocked. runtime selection of
> alternative proxy networks would be a nice feature.

It sounds like you're thinking of Tor as a network of one-hop proxies.
Tor is more modular than that -- in a nutshell, the core Tor protocol
is a protocol to build secure routes through a set of relays, and it
doesn't care where it learns the relays.

> Q: I have noticed lists like: http://proxy.org/tor.shtml that appears
> to be a list of tor proxies. What's to stop the bad guys from blocking
> the entire proxy database? My understanding is that countries like
> Iran have the national ISP market under their thumb.

You might like
https://svn.torproject.org/svn/projects/design-paper/blocking.html
and
https://www.torproject.org/bridges

> PA: There needs to be a way to deal out proxies to clients without the
> ability to easily reveal the entire network to anyone. Perhaps even
> semi-static assignments similar to DHCP. Of course, there is also the
> problem of 'blocking the dealer' similar to the P2P security issues
> with trackers. Ultimately, to really make this fool proof, there would
> need to be a way to communicate proxy dealers offline (verbally /
> off-network) in a concealable way.

That's one approach. I think there other viable approaches too.

> Q: How can we address bad guys blocking port 443.

This actually does happen, e.g. to some people we know in a certain
north African country.

> PA: Proxies should be able to hide behind other services such as
> 25,80,110.

As Justin mentioned, Tor relays (including bridges) can listen on whatever
ports they want.

> Also nice would be a 'spoof greeting' feature that would
> simulate a 'normal' service for that port before a magic code was
> sent. Of course, the magic code would need to be changeable (possibly
> dynamically by a proxy dealer).

See item #10 on
https://www.torproject.org/volunteer.html.en#OtherCoding
which leads to
http://dl.dropbox.com/u/37735/index.html
which needs more work. :)

> Q: What about DPI which can provide encryption protocol info to the
> bad guys (if not the payload).

The best known answer is to try to look enough like some other common
protocol that you mostly blend in. Trying to look like SSL is the clear
best choice at this point.

> PA: plug-in packet obfuscation, possibly agreed upon between proxy and
> dealer and embedded in a magic code given by the dealer to the client
> then provided back to the proxy in the request header. This could be
> implemented by means of a tiny secure VM that ran small byte-code
> obfuscator programs shared between proxy and dealer and referenced by
> the magic code. Even though the bad guys could run the VM
> de-obfuscator, it would be challenging to implement at OSI levels 1-4
> given current technology.

Sounds like a fine open problem. You should investigate it and show us
that it can actually be done, and actually will make it harder to notice
this traffic. Historically, people working on this topic either (at best)
find that it's harder than they thought, or (at worst) overlook why it's
hard and end up with an approach that's less safe than they think.

A good place to start might be to look at papers in the Information
Hiding workshop over the past decade.

--Roger

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/