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 brid...@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 majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/