A few questions and potential answers:
David Bennett
dbennett455 at gmail.com
Mon Sep 20 08:22:57 UTC 2010
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.
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.
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.
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.
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).
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.
--dbennett at bensoft.com
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
More information about the tor-talk
mailing list