server addresses
It seems to me that there ought to be a way to advertise multiple IP addresses for a tor server running on a machine that has multiple interfaces. If multiple Address lines could be specified in torrc, however, that would seem to cause a problem with the format of a descriptor in the directory. This would allow some spreading of bandwidth over multiple links where they are available, though it would not enable real balancing. Secondly, there ought to be a way to advertise a different address for the DirPort from the address for the ORPort, which would allow the server operator to separate the two kinds of traffic onto different subnets or point-to-point links. Perhaps a capability for multiple addresses for the directory service would also be a good thing. At present, about the only things available like this are a) the various *ListenAddress lines in torrc, which depend upon RDRs in a router somewhere, and b) the OutboundBindAddress line, which actually is more likely to defeat balancing than to aid in it. Comments? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
getting more exit nodes
Hi The CCC local group Rheintal [1] is currently working on a solution to get much more Tor exit nodes which we think is a major problem of Tor. The basic idea is to develop a browser plugin which while active turns the computer into both an Tor client and a Tor exit node. The target group is a Windows XP or Vista user with almost no technical skills but fear of pop-ups asking strange things. We are experienced in providing and promoting security software to them [2] and we beliefe that this solution will be accepted and widely used. To get the software done I would like to discuss the technical aspects here. The bigest problem we see are those personal firewalls which prevent running a normal Tor server. Therefore this machine needs to open a client connection. That's why we call it a client-exit node. So we need some servers for the client-exit nodes. This nodes we call pseudo-exit nodes. The reason for this is that Alice selects this node as exit node for its circuit but the traffic gets routed to the client-exit node. So the pseudo-exit node doesn't appear in the server logs. This means that every Tor node can become a pseudo-exit node without any additional law enforcement risks. Given that all Tor nodes are pseudo-exit nodes a client-exit node would select a Tor node at random and connect to it. As soon as a pseudo-exit node has at least one connection to a client-exit node it registers itself at the directory server as a normal exit node. From now on everything goes the normal way except that the pseudo exit nodes passes the traffic which would normally go out of the Tor network to the client-exit node. This is the basic idea. I'm sure there are technical aspects we missed or assumptions which are wrong. So I would appreciate if you could point us on them. We tried hard to find a solution which would not require patching existing Tor nodes. But we didn't find any. Maybe we do in this discussion. [1] http://ulm.ccc.de/Rheintal [2] http://www.dingens.org regards -- Alexander Bernauer
Re: getting more exit nodes
Alexander Bernauer wrote: The basic idea is to develop a browser plugin which while active turns the computer into both an Tor client and a Tor exit node. The target group is a Windows XP or Vista user with almost no technical skills but fear of pop-ups asking strange things. Are you sure it's a good idea to encourage non-technical users, who might not understand the legal risks, to run exit nodes? Cheers, Michael
Re: getting more exit nodes
Hi, On Apr 20, 2008, at 1:32 PM, Alexander Bernauer wrote: [snip] The basic idea is to develop a browser plugin which while active turns the computer into both an Tor client and a Tor exit node. The target group is a Windows XP or Vista user with almost no technical skills but fear of pop-ups asking strange things. We are experienced in providing and promoting security software to them [2] and we beliefe that this solution will be accepted and widely used. I don't think a browser plugin is a good choice for an application that can act as a Tor exit node. Please note how long it takes for a Tor node to be used by clients, and how often Users close their browsers. I think this will produce a huge amount of overhead when such nodes are sending their descriptors and others will try to use them a few hours later, when they have been shut down again. There is another reason why I think a browser plugin is ill suited: In my opinion, users want browser plugins for a specific purpose, for example play a movie or block Flash. They don't want a plugin that does arbitrary things they don't quite understand. If you find a good solution for how to make use of Tor relays behind restrictive firewalls, that'd be most awesome, but I think such an approach should be included in the Tor software. Note that currently, any relay must be able to connect to any other relay. Sebastian
Re: getting more exit nodes
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 co
Re: getting more exit nodes
Hi On Sun, Apr 20, 2008 at 02:47:34PM +0200, Sebastian Hahn wrote: > Please note how long it takes for a Tor node to be used by clients, How long is that? Are there any statistics about that? > I think this will produce a huge amount of overhead when > such nodes are sending their descriptors and others will try to use > them a few hours later, when they have been shut down again. This problem exists as soon as end-user's computers become Tor nodes. How is this solved currently? Are all Tor nodes servers with high uptimes? > They don't want a plugin that does arbitrary things they don't > quite understand. We will see. We don't insist on having a browser plugin. > If you find a good solution for how to make use of Tor relays behind > restrictive firewalls, that'd be most awesome, but I think such an > approach should be included in the Tor software. Well, until now I think my proposed solution could work. > Note that currently, any relay must be able to connect to any other > relay. Client-exit nodes are no normal relays. They have no incoming connections. They are simply the log scapegoats for the pseudo-exit nodes. cu -- Alexander Bernauer
Re: getting more exit nodes
Alexander Bernauer schrieb:
Please note how long it takes for a Tor node to be used by
clients,
How long is that? Are there any statistics about that?
AFAIK the minimum is about 2-3 hours until a router descriptor is
properly distributed through the directory mirrors and clients.
I think this will produce a huge amount of overhead when such
nodes are sending their descriptors and others will try to use
them a few hours later, when they have been shut down again.
This problem exists as soon as end-user's computers become Tor
nodes. How is this solved currently? Are all Tor nodes servers with
high uptimes?
I think, any routers with uptimes less then 4-6 hours will be more or
less useless for the network and rather tend to produce more traffic
for distributing the router descriptor than relay for clients. But I
am no expert for this kind of question.
Not all Tor nodes have high uptimes. The uptime is only interesting
for routers. Each router descriptor has a flag ("stable") in its
descriptor, which is set for routers with a certain minimum uptime and
availability. In many circuits, stable routers are preferred.
For details concerning all these stuff please read the technical
design papers, I assume, they will be very helpful for your project. ;-)
http://www.torproject.org/documentation.html.de#DesignDoc
http://www.torproject.org/svn/trunk/doc/spec/dir-spec.txt
http://www.torproject.org/svn/trunk/doc/spec/path-spec.txt
http://www.torproject.org/svn/trunk/doc/spec/tor-spec.txt
Bye,
Dominik
Re: getting more exit nodes
On Sun, Apr 20, 2008 at 01:03:21PM +0100, Michael Rogers wrote: > Are you sure it's a good idea to encourage non-technical users, who > might not understand the legal risks, to run exit nodes? I don't see how we can establish an anonymous transport system without risk dispersing. If there are enough participants the individual risk becomes small. Compared to the risk to which many users already are exposed because theire computer is hacked and serves in a bot net this additional risk should be small. But we don't want to trick anybody. The risks will be explained and the user is free to choose. cu -- Alexander Bernauer
Re: getting more exit nodes
Michael Rogers schrieb: Alexander Bernauer wrote: The basic idea is to develop a browser plugin which while active turns the computer into both an Tor client and a Tor exit node. The target group is a Windows XP or Vista user with almost no technical skills but fear of pop-ups asking strange things. Are you sure it's a good idea to encourage non-technical users, who might not understand the legal risks, to run exit nodes? This an important point. If there is a software, which establishs a Tor router on a computer without _informed_ consent of the admin, we're getting close to botnets. Something like that could severely hurt Tor's repution. It is really important for people to know beforehand what Tor (basically) does and what major legal risks it may pose in their jurisdiction. That might even go as far as a risk for their life. Bye, Dominik
Re: getting more exit nodes
I just comment on some points as I don't have much time. Michael Schmidt schrieb: 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. [...] So I appreciate the new tit-for-tat paragdim and development start: everyone who uses tor, must be with his IP an exit node. That approach would almost certainly kill Tor. There are plenty of reasons (technical, legal or social) which either prevent someone from operating a Tor (exit) relay or make it is least hazardous. I operate 2 Tor relays on dedicated machines and use Tor as client on my laptop. I refuse to relay traffic on my laptop. Why? Because I use my laptop in networks (such as the one at work) where I am simply not allowed to relay traffic or operate server processes. It could cost my job. If I visit networks of my friends I also won't be rude enough to try to relay traffic. If I am dissident in some country with oppressive government or a whistle-blower then the last thing I want to do is attracting attention by relaying Tor traffic... Use you imagination, why forcing people to operate relays is a bad idea. an now the interesting thing c) Breaking through a firewall: Breaking through the firewall of a secured net is probably a really good reason for instant dismissal for many employers, because it may put the local net at risk. Especially if it done to serve the employers ressources (network connectivity) to a third party. So you see.,. in the end, the firewall breakout is trivial and only a technical thing. I completely disagree with that. 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!! Such a 'darknet' approach is certainly interesting, but it has severe consequences for anonymity. They can be used to map social relationships by monitoring which nodes communicate with which other nodes. So the conclusion is: only the web of trust underlaying architecture allows to hide serverlists from public view. Last time I heard something about it, it is not intended to hide the exit tor servers from the public. Quite the contrary. The Tor project specifically has the TorDNSEL service: http://exitlist.torproject.org/ https://tor.eff.org/svn/trunk/doc/contrib/torel-design.txt Bye, Dominik
Re: getting more exit nodes
On Sunday 20 April 2008 12:32:19 Alexander Bernauer wrote: > Hi > > The CCC local group Rheintal [1] is currently working on a solution to > get much more Tor exit nodes which we think is a major problem of Tor. > > The basic idea is to develop a browser plugin which while active turns > the computer into both an Tor client and a Tor exit node. The target > group is a Windows XP or Vista user with almost no technical skills but > fear of pop-ups asking strange things. We are experienced in providing > and promoting security software to them [2] and we beliefe that this > solution will be accepted and widely used. > > To get the software done I would like to discuss the technical aspects > here. > > The bigest problem we see are those personal firewalls which prevent > running a normal Tor server. Therefore this machine needs to open a > client connection. That's why we call it a client-exit node. > > So we need some servers for the client-exit nodes. This nodes we call > pseudo-exit nodes. The reason for this is that Alice selects this node > as exit node for its circuit but the traffic gets routed to the > client-exit node. So the pseudo-exit node doesn't appear in the server > logs. > This is an interesting idea - I submitted a proposal with broadly similar aims a little while ago. Though the approach was completely different. I suggest you write the idea up using the proposal format and post it to or-dev. That process will help you consider the security/anonymity implications of what you're suggesting. It will also reveal if there are any tricky implementation issues that need working out. A couple that occur to me: - Client traffic is being routed through an exit node that was not explicitly chosen by the client. Does this have any unintended consequences for anonymity? - Should pseudo-exits mark themselves as vanilla exits, or as something else? - What exit policy should they advertise? - How do the client-exits authenticate themselves to the pseudo-exit? Do they upload descriptors to the authorities? > This means that every Tor node can become a pseudo-exit node without any > additional law enforcement risks. Given that all Tor nodes are > pseudo-exit nodes a client-exit node would select a Tor node at random > and connect to it. As soon as a pseudo-exit node has at least one > connection to a client-exit node it registers itself at the directory > server as a normal exit node. From now on everything goes the normal way > except that the pseudo exit nodes passes the traffic which would > normally go out of the Tor network to the client-exit node. > > This is the basic idea. I'm sure there are technical aspects we missed > or assumptions which are wrong. So I would appreciate if you could point > us on them. > > We tried hard to find a solution which would not require patching > existing Tor nodes. But we didn't find any. Maybe we do in this > discussion. > > [1] http://ulm.ccc.de/Rheintal > [2] http://www.dingens.org > > regards signature.asc Description: This is a digitally signed message part.
Re: getting more exit nodes
On Sun, Apr 20, 2008 at 05:41:57PM +0200, Dominik Schaefer wrote: > I think, any routers with uptimes less then 4-6 hours will be more or > less useless for the network and rather tend to produce more traffic > for distributing the router descriptor than relay for clients. Well, in theory the "client-exit" nodes don't need to send their descriptors to any users. They just need to have an association with a Tor relay so the relay learns quickly when they're available. Then the relay can advertise itself with the exit policy of the client-exit node, and so long as it has some client-exits available whenever an exit request shows up, it can pass it on. Here are a few other things that would be useful to consider before we can evaluate the idea: - Bug 98. If you run too many connections through a Tor process on Windows, the OS will crash. We (meaning Nick) are slowly working on that, but it is not yet solved. - Robert Hogan's questions in this thread are good to look at. In particular, does the relay actually advertise the client-exit's exit policy as its own? - Need to consider load balancing. Right now users will choose the relay proportional to the bandwidth it advertises. But if it's a fast relay and the client-exit node is slow, the client-exit node will get overloaded and things will be even slower than they are now. - Related to load balancing: how much additional latency are we talking about, from adding a fourth hop to the circuit? Because it would seem that you need four hops, since the "relay to client-exit" hop isn't adding much additional anonymity. (Or is it?) - How is the crypto going to work between the relay node and the client-exit node? Are you planning to put a Tor process on the client-exit node, or were you just hoping to put a tiny proxy on it? Probably there are more issues to explore after these. Hope that helps, --Roger
Re: Torbutton 1.1.18-alpha released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 when i click on the history menu, my history is displayed, even though "block history reads during tor" is checked. before, with 1.1.17, i am pretty sure, the history menu would come up blank. is this ok? thx. -BEGIN PGP SIGNATURE- iD8DBQFIDDJjXhfCJNu98qARCPfuAKCkrdsb1+OUzEm8lB8Ycx47Nycz1ACg+dQZ i/wV4bZCmh/Hv+R0tBOUOaA= =LRge -END PGP SIGNATURE-
Re: getting more exit nodes
Roger Dingledine schrieb: - Related to load balancing: how much additional latency are we talking about, from adding a fourth hop to the circuit? Because it would seem that you need four hops, since the "relay to client-exit" hop isn't adding much additional anonymity. (Or is it?) I believe this to be the most interesting question... since the user does not know his connection will be relayed via a client-exit, there will only be encryption up until the last relay (the one advertising itself as an exit). Therefore, even if you re-encrypt the data for transfer to the client-exit, it will now be *two* hops being able to read the user's traffic in cleartext. I don't think that's an improvement... I'd even go as far as saying it's the exact opposite of what we want. Plus, having the last relay re-encrypt the connection will add additional CPU and RAM load, which IMHO is not a good idea. Regards Andrew
