Re: Tor From SVN on Weelky Basis
On Sun, Nov 2, 2008 at 12:56 AM, [EMAIL PROTECTED] wrote: On Sat, Nov 01, 2008 at 11:52:29PM -0500, [EMAIL PROTECTED] wrote 0.2K bytes in 8 lines about: : Is there any good reason not to build Tor from the SVN on a weekly basis or so? Given the active coding, svn trunk may break your anonymity [...] The instance I am referring to runs as a server only. I have an old HP Kayak (PIIIx5000mhz baby!) that I use as my workhorse computer, not (normally) for web browsing etc. Just a couple different severs and backup storage. allow security issues, For me or the network? consume all your ram, I don't monitor it all that closely. and sour your milk. I'll buy more more :-) Otherwise, feel free. Please do report bugs as you encounter them. As I mentioned I don't monitor it that closely, just usually make sure it is up and running. Is it running properly as an exit node (usually obvious by number of outgoing connections/bandwidth from it). Is there something specific I should be looking for? I often write scripts to try to automatically build programs that I either use often, always like the latest and greatest on, or prefer [the projects prefer] that one run the latest from the SVN/CVS. I am running Ubuntu 7.10. Given the above, any reason not to recompile from the SVN weekly or so? For the sake of the network should I use an official stable or alpha release? Thanks Phobos/Andrew. I do my best to answer newbie problems as best as I can and as have time on this list but do read it regularly and appreciate your attention to it. -madjon -- Andrew
Re: Problems starting relay
On Sun, Nov 2, 2008 at 1:39 AM, Geoff Down [EMAIL PROTECTED] wrote: Hi, I'm not mirroring the directory server (yet) so I assume I don't need to worry about the directory port. I did enable UPnP on my router (temporarily) and tried the Test button in the Vidalia Relay setup page, and it reported 'Success'. However, on examining the Port Forwarding page, there was then no sign of a rule for Tor or Vidalia. I disabled UPnP after that. I'm using OSX 10.3.9. I went into the Firewall section of 'Sharing' and added a rule for Tor: This is your firewall entry for Tor: it is currently on and all TCP network traffic on port(s) 9001 is being let through. Yet still I get [Warning] Your server (xx.xx.xx.xx:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc My Port Forwarding rule (added manually) says Protocol TCP Port Start 9001 Port End 9001 Port Map 9001 Is there a way I can check the Port Forwarding independently of Tor? Thanks, GD On 2 Nov 2008, at 05:54, [EMAIL PROTECTED] wrote: On Sun, Nov 02, 2008 at 05:45:40AM +, [EMAIL PROTECTED] wrote 3.5K bytes in 113 lines about: I downloaded the Vidlalia/Tor/Privoxy bundle all together. Then all you need to do to run a relay is configure one via the Vidalia Setup Relaying button in the Vidalia Control Panel. Tor will generally figure out the rest. If your router supports upnp, Vidalia will attempt to configure any port forwarding for you. If not, then yes, you need to port forward your orport and dirport from the external router to your machine. If for some reason you use the osx firewall, you'll also need to open the tcp ports for the orport and dirport. If you are using 10.5 (leopard), when you configure a relay through vidalia, the system should ask you to allow or deny the correct ports. The easiest next step may be to start with a fresh torrc and let Vidalia do the work of configuring the relay. -- Andrew First, take any advice from Phobos before mine. Second, I opened up Vidialia on my computer (I'm old school and usually do this in a text editor); under sharing what is the Relay Port set to? Is it the same as what your router currently has configured? I *think* the default (under Vidalia 0.1.9) is 443, not 9050. Make sure your router reflects that. Finally, note what Phobos said above about using the OSX firewall. It could be getting in the way (says the guy who only runs Windows Linux) -madjon
Re: Problems starting relay
On Sun, 2 Nov 2008 06:39:31 + Geoff Down [EMAIL PROTECTED] wrote: I'm not mirroring the directory server (yet) so I assume I don't need to worry about the directory port. I did enable UPnP on my router (temporarily) and tried the Test button in the Vidalia Relay setup page, and it reported 'Success'. However, on examining the Port Forwarding page, there was then no sign of a rule for Tor or Vidalia. I disabled UPnP after that. I'm using OSX 10.3.9. I went into the Firewall section of 'Sharing' and added a rule for Tor: This is your firewall entry for Tor: it is currently on and all TCP network traffic on port(s) 9001 is being let through. Yet still I get [Warning] Your server (xx.xx.xx.xx:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc My Port Forwarding rule (added manually) says Protocol TCP Port Start 9001 Port End 9001 Port Map 9001 Is there a way I can check the Port Forwarding independently of Tor? Take some time out here to RTFM. (Likewise to madjon, who posted thoroughly bogus directions in response to your initial posting.) After doing that, you may find that you understand enough of what you're writing about that you can get it set up correctly. If you can't get it to work after RTFM, *then* come back to the list. At least you'll better equipped to pose your questions and understand the responses. Thus far it is obvious that you don't understand your own network setup and have yet to RTF tor M. Until you've read the basics, all you're doing here is generating noise, not helping your situation, and possibly mucking up your setup in ways that may be hard to backtrack from. A person who does understand his/her local network setup may well be able to configure a basic relay successfully just based upon the comments in torrc, though the man page might clarify a detail here or there. 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 * **
Re: Problems starting relay
snipped much (Likewise to madjon, who posted thoroughly bogus directions in response to your initial posting.) My sincere apologies. I didn't RTFM, only going off of my own experience. Apparently a bad idea. 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 * ** -madjon
Re: Tor From SVN on Weelky Basis
On Sun, Nov 02, 2008 at 01:31:52AM -0500, Jonathan Addington wrote: I am running Ubuntu 7.10. Given the above, any reason not to recompile from the SVN weekly or so? For the sake of the network should I use an official stable or alpha release? Should be fine. We try to fix known problems in svn as we encounter them, so trunk is usually pretty stable. There are occasionally crash bugs that take us a couple days to fix; in those cases you might want to hang out in irc to hear how they're going. Please do report any problems you find. So yes, at least in theory, running trunk should be fine. I keep my Tor client as up to date as possible, to see if I can make bugs happen. I also periodically upgrade my directory authorities to trunk to try to get them to crash before new releases. --Roger
Re: Tor From SVN on Weelky Basis
On Sun, Nov 2, 2008 at 2:20 AM, Roger Dingledine [EMAIL PROTECTED] wrote: On Sun, Nov 02, 2008 at 01:31:52AM -0500, Jonathan Addington wrote: I am running Ubuntu 7.10. Given the above, any reason not to recompile from the SVN weekly or so? For the sake of the network should I use an official stable or alpha release? Should be fine. We try to fix known problems in svn as we encounter them, so trunk is usually pretty stable. There are occasionally crash bugs that take us a couple days to fix; in those cases you might want to hang out in irc to hear how they're going. Please do report any problems you find. So yes, at least in theory, running trunk should be fine. I keep my Tor client as up to date as possible, to see if I can make bugs happen. I also periodically upgrade my directory authorities to trunk to try to get them to crash before new releases. --Roger Thanks much Roger, -madjon
Re: Problems starting relay
Seems to be working now - with ORListenAddress 0.0.0.0:9001 . Thanks to those who actually tried to help with suggestions, correct or otherwise. GD On 2 Nov 2008, at 06:52, Jonathan Addington wrote: On Sun, Nov 2, 2008 at 1:39 AM, Geoff Down [EMAIL PROTECTED] wrote: Hi, I'm not mirroring the directory server (yet) so I assume I don't need to worry about the directory port. I did enable UPnP on my router (temporarily) and tried the Test button in the Vidalia Relay setup page, and it reported 'Success'. However, on examining the Port Forwarding page, there was then no sign of a rule for Tor or Vidalia. I disabled UPnP after that. I'm using OSX 10.3.9. I went into the Firewall section of 'Sharing' and added a rule for Tor: This is your firewall entry for Tor: it is currently on and all TCP network traffic on port(s) 9001 is being let through. Yet still I get [Warning] Your server (xx.xx.xx.xx:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc My Port Forwarding rule (added manually) says Protocol TCP Port Start 9001 Port End 9001 Port Map 9001 Is there a way I can check the Port Forwarding independently of Tor? Thanks, GD On 2 Nov 2008, at 05:54, [EMAIL PROTECTED] wrote: On Sun, Nov 02, 2008 at 05:45:40AM +, [EMAIL PROTECTED] wrote 3.5K bytes in 113 lines about: I downloaded the Vidlalia/Tor/Privoxy bundle all together. Then all you need to do to run a relay is configure one via the Vidalia Setup Relaying button in the Vidalia Control Panel. Tor will generally figure out the rest. If your router supports upnp, Vidalia will attempt to configure any port forwarding for you. If not, then yes, you need to port forward your orport and dirport from the external router to your machine. If for some reason you use the osx firewall, you'll also need to open the tcp ports for the orport and dirport. If you are using 10.5 (leopard), when you configure a relay through vidalia, the system should ask you to allow or deny the correct ports. The easiest next step may be to start with a fresh torrc and let Vidalia do the work of configuring the relay. -- Andrew First, take any advice from Phobos before mine. Second, I opened up Vidialia on my computer (I'm old school and usually do this in a text editor); under sharing what is the Relay Port set to? Is it the same as what your router currently has configured? I *think* the default (under Vidalia 0.1.9) is 443, not 9050. Make sure your router reflects that. Finally, note what Phobos said above about using the OSX firewall. It could be getting in the way (says the guy who only runs Windows Linux) -madjon
[no subject]
If you run as an exit node, it's my understanding that you also act as a middleman node. Would it be possible, and would it be a good idea, to add an option such that you only act as an exit node? It seems a bit of a waste to use potential exit bandwidth as middleman relaying bandwidth when exit bandwdith is more scarce. -- Erilenz
Re: exit nodes always also being middle nodes
Quoth Erilenz [EMAIL PROTECTED], on 2008-11-02 08:50:11 -0500: If you run as an exit node, it's my understanding that you also act as a middleman node. Would it be possible, and would it be a good idea, to add an option such that you only act as an exit node? And then an attacker can guess that any streams coming in to you must be exiting from you, as opposed to making it harder for them to know whether they're exiting there or being bounced somewhere else. (Note that the attacker may be the middle node, though I'm not sure that makes a difference.) --- Drake Wilson
Found a bug in documentation on the site?
Ciao a tutti, I was making some experiments with fetchmail + tor and I found a strange behaviour: at the address https://wiki.torproject.org/noreply/TheOnionRouter/TorifyHOWTO/EMail there is this example: set no spambounce set no bouncemail poll provider plugin socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050 protocol imap user user with password password, ssl mda /usr/bin/procmail -d userlocal but sniffing the traffic I see a dns query for the address of provider _at the beginning_ of session: looks like fetchmail doing these queries at the beginning of the session without any help from socat and only then it calls socat to download the messages, actually (?) late. I think this behaviour must at least indicated in that page. -- Ciao leandro Un esteso e normale uso della crittografia è il sistema più forte per rivendicare il diritto alla privacy nelle comunicazioni telematiche: come tutti i diritti e come i muscoli se non viene esercitato costantemente si atrofizza e va perso. pgpwHtA7TcSnv.pgp Description: PGP signature
Re: exit nodes always also being middle nodes
On Sun, Nov 02, 2008 at 08:50:11AM -0500, Erilenz wrote: If you run as an exit node, it's my understanding that you also act as a middleman node. Would it be possible, and would it be a good idea, to add an option such that you only act as an exit node? It seems a bit of a waste to use potential exit bandwidth as middleman relaying bandwidth when exit bandwdith is more scarce. Actually, clients weight their path selection based on whether you're an exit. So they look at how scarce exit bandwidth is, and choose your exit proportionally less for non-exit positions. See https://www.torproject.org/documentation.html.en#DesignDoc which points to https://svn.torproject.org/svn/tor/trunk/doc/spec/path-spec.txt and section 2.2 explains more. We also do a similar weighting for the entry position (see section 5). --Roger
Future Development on Hidden Services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, as some of you may know, there have been several improvements to hidden services lately. First, hidden services publish their descriptors to a distributed directory [1] consisting of currently 71 nodes. Second, hidden services may require client authorization already during connection establishment to block unauthorized requests as early as possible [2]. Third, hidden service performance has been improved with respect to advertising and accessing hidden services [3,4]. Certainly, there are still things that can (and should) be improved. This is an attempt to compile a good list of future development tasks on hidden services. Comments are most welcome. If there are other things with hidden services that need improvement, please let us know. - --Karsten 1. Further improve performance and reliability - -- In the current NLnet project on speeding up hidden services [3] we found and fixed a lot of performance-related bugs, identified the likely bottlenecks of the protocol, and added the most important performance improvements to the code [4]. But there are still some possible improvements left that require evaluation and possibly coding if they turn out to be useful: a. Descriptor fetches on client side are an issue. Most failed connection establishment occur when trying to fetch the descriptor of a hidden service. We could parallelize this step as well (maybe also in combination with a certain delay to avoid extensive network load), just as we do with client-side requests to introduction points [4]. This might speed things up and lead to better reliability (at the price of increasing the number of requests to the distributed directory). b. The client-side request timeout of 60 seconds could be improved. It doesn't make sense to have a 60-seconds timeout for 5 substeps and stick to it even when realizing that the first substep has already taken 55 seconds. The other 4 steps (that are invisible to the client) simply cannot succeed in that time. This would also improve reliability, because we are otherwise giving up on requests that succeed soon after. c. The INTRODUCE1 cells could be combined with the first BEGIN cell to initialize an application stream. After establishing a 6-hop circuit from client to service, the client still needs to initialize an application stream over it which takes another 6 seconds in the mean. Maybe there is a chance to send the stream initialization message already as part of the introduction request. Or the hidden service could initialize the first stream back to the client. There might be security implications that prevent this, so more thoughts are needed here. d. Adapt the protocol to low-bandwidth environments: The effects of low-bandwidth connections on either accessing or running hidden services has not been investigated so far. Maybe such environments require us to change parameters like timeouts when we realize that our connection is bad. Jörg Lenhard is currently working on measurements using telephone and cell phone connections that hopefully give us some new insights. e. One of the big performance issues is general Tor circuit-building performance. This comes in two pieces: First, extending a circuit in Tor has a nontrivial chance of timing out or failing. Second, extending a circuit in Tor takes too long, both in terms of mean and in terms of variance. These problems are magnified for hidden service use, a) because the path is twice as long, and b) because some components of the path really do need to be made on demand, whereas for normal Tor circuits you make the whole circuit beforehand. So, if this improves for general circuits in Tor, hidden services should inherit these performance gains 'for free'. 2. Improve hidden services with client authorization - Beginning with version 0.2.1.6-alpha, hidden services support client authorization. That means that hidden services can restrict access to a small set of clients and prevent other clients (or introduction points/directory nodes) from establishing a connection. When client authorization is applicable, it reduces the risk of certain attacks on locating hidden servers [6] or denial of service. Once this feature is more tested, people should be told that it exists and how to use it. a. Make client authorization for hidden services easier to use: Domenik Bork has made a start on making Vidalia support configuration of hidden services with client authorization in his GSoC project [7]. His changes will hopefully be merged into Vidalia trunk quite soon. The question is whether people understand the interface, or if this needs improvement. b. Write good howtos for both service operators and clients: First, explain to the service operator what steps are required to add or remove authorization for a given client. Second, help end users understand how to
Re:
when choosing the middle nodes, it excludes the exit node and other middle nodes first. and then exclude itself if it's a or. and randomly choose a node in the running routers list which contains all those routers only if it's now running and valid and you think it's reliable enough. so actually i don't see there's some policy to exlude those exit nodes On Sun, Nov 2, 2008 at 9:50 PM, Erilenz [EMAIL PROTECTED] wrote: If you run as an exit node, it's my understanding that you also act as a middleman node. Would it be possible, and would it be a good idea, to add an option such that you only act as an exit node? It seems a bit of a waste to use potential exit bandwidth as middleman relaying bandwidth when exit bandwdith is more scarce. -- Erilenz
Re:
On Mon, Nov 3, 2008 at 2:42 PM, 臧美君 [EMAIL PROTECTED] wrote: when choosing the middle nodes, it excludes the exit node and other middle nodes first. sorry, i'm saying it excludes the exit node and the other middle nodes first in the same path and then exclude itself if it's a or. and randomly choose a node in the running routers list which contains all those routers only if it's now running and valid and you think it's reliable enough. so actually i don't see there's some policy to exlude those exit nodes On Sun, Nov 2, 2008 at 9:50 PM, Erilenz [EMAIL PROTECTED] wrote: If you run as an exit node, it's my understanding that you also act as a middleman node. Would it be possible, and would it be a good idea, to add an option such that you only act as an exit node? It seems a bit of a waste to use potential exit bandwidth as middleman relaying bandwidth when exit bandwdith is more scarce. -- Erilenz
