A few questions and potential answers:

[Aplin, Justin M]

  On 9/20/2010 4:22 AM, David Bennett wrote:
> Bad Guys == Anyone blocking or monitoring a persons access to knowledge

Granted.

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

Perhaps I don't understand what you're going for here. If a user is 
using https (or another client-server encryption protocol), then a "bad 
guy" viewing traffic without the onion-layer encryption would simply see 
more encrypted traffic. Even if the user does not (or cannot) use 
https-like protocols, because each node does not know where along the 
circuit it lies, this is no more useful than passively monitoring an 
exit-node's traffic for information. That said, there are plenty of 
warnings on the project website about this: tor is not magic, and users 
need to be careful that any unencrypted traffic does not contain any 
personally identifiable information.

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

The volunteer model is exactly what keeps tor afloat: nodes appear and 
disappear all the time, and traffic to many of them looks innocuous, as 
if they were connecting to any other computer on the net. See below.

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

There are many bridges that are only distributed on request via 
https://bridges.torproject.org and via email to bridges at torproject.org. 
These change dynamically enough to keep most users connected. Where 
access is blocked, mirrors and relays can be found with a little 
fenangling about search engines.

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

See above. As I understand it, as soon as a client can connect to a 
single bridge, they can then obtain enough information to build circuits 
without needing to refer to any central authority.

> Q: How can we address bad guys blocking port 443.
>
> PA: Proxies should be able to hide behind other services such as
> 25,80,110. 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).

Tor bridges and exits are in no way limited to port 443. My exits 
currently use port 9001, with directory mirrors on port 9050; this is 
the purpose of the orport and dirport lines in the torrc. I'm not 
qualified to comment on why the rest of your proposal would or would not 
be a good idea.

> Q: What about DPI which can provide encryption protocol info to the
> bad guys (if not the payload).
>
> 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.
>
> The ultimate idea would be to keep the Bad Guys busy chasing their
> tails and break them through over investment in competence. As they
> attempt to keep up with the changing methodologies they become victims
> of their own system of control, meanwhile they have less time to do
> their normal bad guy stuff. Basically, the circumvention tool itself
> becomes an agent provocateur.

Again, not qualified. I hope someone will provide a better answer to this.

~Justin Aplin
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/