getting more exit nodes

Sun Apr 20 14:13:39 UTC 2008

Hello Alexander, and list,

that is an essential idea, which is now discussed, and that start of that
development is still missing. So good to hear.

First, I agree (as posted earlier), that we need a tit-for-tat Tor:
Everyone who wants to surf with the IP of another peer, needs to give his IP
as well, so that others can surf.

That was the idea of peek-a-booty software, which stalled in development.

We raised the question to have a special browser with this exit-node tor
implemented to jap and roger and torpark.
But noone ever came up with any solution.
So I appreciate the new tit-for-tat paragdim and development start:
everyone who uses tor, must be with his IP an exit node.

Similar archtectures were discussed for friends of friends, e.g. over
http://retroshare.sf.net - there is already code (i can send or see the
feature request postings with the patch) where a friend is a proxy for all
his friends..

You now mention the firewall problem...
here i might be allowed to suggest as well this kind of architecture, which
helps in three ways:

a) surfing of all friends through my IP: psiphon or retroshare patch
b) installing on certain retroshare nodes a tor node, so that both are in a
superpeer modus:
friends can surf over rs friends and select the ip of the friend, or the tor
circuit. that is a limited design, as only friends can choose that server
and for the peers from the tor network choosing this exit node, it makes no
difference. so for the friends it is just a normal proxy, they share with
the option to step into a tor circuit. Though--- that way one RS friend in
the USA would allow many friends to choose that exit-ip. or that tor-entry
ip. (without the ISP logging, as RS is encrypted transfer)

an now the interesting thing c) Breaking through a firewall:

RS has implemented openDHT and other RS nodes work as a STUN server, so the
connection can break through every firewall.

The idea is now, to use any retroshare node to make the firewall
breakthrough for the TOR-Client-Firefox node.
That design uses not the f2f-connections, but the network only for the
firewall breakthrough (initial Stun).
Of course you can install as well any central STUN server.

The problem with this design is, if the (central or public known) stun
server is killed (or the forwarding tor server), then many client-exit-nodes
(the firefoxusers) are killed.

(and of course the users doing evil things to them with the ip of the
client-exit node... so here is the real problem, not showing the IP of the
pseudo-exit node not in the tor-server list).

You request a total change to a p2p network, away from the client-server
approach. That was peek-a-booty.

so your idea has two main impacts:
- firewall breakthrough
- hidden client-exit-nodes (covered by the IP of the proxy-forwarding
(stun)server)

As said: the p2p network needs no serverlist, just any user as an outproxy
and every user testing TOR can accuse any IP - the one with which he surfs -
to shut down the exit node. Indifferent, if it is a pseudo or normal or
client exit node.

I would speak then of a "professional server exit node" and an
"at-home-Firefox-private-exit-node", and because of the firewall, the
private exit nodes need a stun server or "reflector" (term from cucme) or a
proxy or a forwarding server - however you want to call it.

professional exit node = Tor servers (appear in the list)
refelctors = Pseudeo-exit nodes
Private exit nodes = Firefox users, connecting to reflectors, getting the
requests forwarded from them.

So the hiding of the IP of the private exit node is not the issue..
(though with your design they do not appear in the list of the (normal tor)
client, but every user can surf, see the exit-ip and take it down (= test if
there is a log, if not -> accuse )).
That is the same problem with the emule clients.. which show the IP
downloading a file.

Using the STUN/proxy servers or reflectors to hide them, helps, but then the
target are these STUN pseudo-server. If one is down, many private or
client-exit nodes are down.

And how do clients find the list of refelctors? so you have the same problem
in the Firefox client, which you have now in the tor client serverlist.
("Note that currently, any relay must be able to connect to any other
relay.)
That idea is simple:

1. I agree not to make a browser plugin, but to stick it to any other always
running software.
Then because of the revealing cockies while switching tor on and off in the
browser, it would be good to have an own browser, with different gui
colours, so that users know, with that browser: I surf with a different ip.

2. Make Tor tit-for tat for that deamon.

3. Stun the deamon with retroshare (as it is a p2p stun network and not a
cental stun server) and then users need to install both.

(btw. the Qt gui of RS has as well a browser widget, so you can implement as
well a small browser there, or link to localhost for your normal browser.)

What is then the function?:
e.g. all private-exits could even perform a new network, STUN by RS.
or: the professional exit nodes are as well given, but then the
client/private exit nodes are listed in each serverlist.

In the end, though roger might not like the idea, I believe, that we need
trusted privat friend to friend connetions to such reflector servers.

That means, I surf over RS to another RS user, whom I trust, and here I find
a reflector or a direct exit point.

That means, this client is free of any serverlist...
And for the reflector... this means, he is not reporting any client nodes
(friends) to any professional servers. As he chooses any friend out of his
list (by random) to forward the request from normal tor clients or
professional circuit tor servers (or other friends).

So you see.,. in the end, the firewall breakout is trivial and only a
technical thing.

The hiding of the leaves.. or client-nodes is not really helping, as you see
in emule: downloading shows the IP of the file-hoster/inserter or the
client-exit-node and makes only the reflector servers the target.

any test to surf with client-exit nodes showing a german ip rises the
question: how is data retention done.. as it is not, the users are still
accusable.

You only can get away from that problem, if the connection to an exit node
is done by trusted friends in europe, while the exit node/reflector is
outside the law.

The solution to the problem is, that private persons allow private
persons/friends to surf with his own IP adress, while that IP is NOT listed
in the public!!

Or the other way round: the problem are the (public) list of tor-servers.
We need to find tor server to forward the request, to a bunch of other
IP-adresses out of a cache, while each client has another list in this
cache.
That is the list of friends each one has!!
while peers are public, friends are private and really, i believe, that the
protocol needs this extention, that the route of the circuit over peers is
broken by one hop over friends, as only this hop guarantees an IP as an exit
node, which is not listed in the public.

one retroshare node with an tor-reflector node in the USA allows all 10
friends in europe to be exit points, which are not know in the tor world.
furthermore in the other way, these 10 friends can surf through the
reflector which forwards to another relector and then to another group of
frieds (which have as well their IP adresses not listed in the public).

You see, each reflector is a gatekeeper with a bunch of friends. Friends
from villariba surf over both gatekeepers with the IP of friends from
villabacho.

The connection then between/amoung reflector nodes itself and their
connection to the normal peer-based tor network might reveal then all IP
adresses of the reflector nodes.. so they are still able to take down.

For that then you need as well a web of trust (excluding private peers)
amoung the reflector nodes.

These nodes are then only accusable, if the evil man sets up as well an
relfector, to find out all the other reflectors. (that means a new network,
reflectors not conneced to public tor server lists)

as they are a kind of multiplicators or supernodes, it is a big damage, if
one of them is gone, but if every reflector is only aware of a small list of
others, then the IP of that reflector is not in the public.

anyway... just some thoughts and the resticted list of nodes is still an not
solved problem. Hidden services might help?

Ideally you want a new network, in which you get in a DHT a list of all
nodes, which are all exit nodes, yourself including,
you just need one Ip to bootstrap and then just choose any peer which is
online, to use him as an exit point. (to prevent data retenmtion, one hop
mixing)  oR: that amoung these participating nodes tor circuits are
establisehd (proxy network not only to change IP, but also to hide IP).

For that application you of course need a port forwarding, if not STUNed by
another peer (see how RS has solved this, above).

And this network is quite easy to do:

just make every tor user an exit node.. then the list is very long...
and you pic up any ip to surf with only one hop or to build normal longer
circuits.

But then the police can ask any listed IP, if the logs are running or not -
and they can even ask the ISP for that,
And so the conclusion is: you need to run one hop over encrypted retroshare
friend, then the ISP does not know, that there were tor traffic sent (or to
whom (of your 10 budies) it was sent), and you yourself are sure, that the
pseudo-exit node (reflector) does not offer your IP, if you are with your RS
node an exit point (because that/your rs node is as well a tor node, which
could forward!! or even act as a reflector...).

Ideally you do surfing over a kind of turtle hopping (circuits over a web of
trust), while each friend in the chain allows to exit.
http://www.turtle4privacy.org/new/
http://www.turtle4privacy.org/documents/en_what_is_turtle_f2f.ppt

So the conclusion is: only the web of trust underlaying architecture allows
to hide serverlists from public view.
And the most developed wot is RS.
http://sourceforge.net/forum/forum.php?thread_id=2002796&forum_id=618174
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20080420/6553e2bc/attachment.htm>