Re: getting more exit nodes

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.

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:

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)

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

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.

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.

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

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.

So the conclusion is: only the web of trust underlaying architecture allows to hide serverlists from public view.