[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: A few questions and potential answers:
On 9/20/2010 4:22 AM, David Bennett wrote:
Bad Guys == Anyone blocking or monitoring a persons access to knowledge
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@xxxxxxxxxxxxxxx
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.
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/