Re: Running a stable exit node without interference (Was blutmagie quad core upgrade)
On Sat, May 08, 2010 at 01:57:02PM +0300, maill...@piirakka.com wrote 1.2K bytes in 44 lines about: : Okay, that cleared things a lot. I Guess that authorities treats that : ip-range as an ISP. : : Last week I was in contact with my ISP and it is possible to have your : companys etc. information on the ip-range that you use but still it : shows also the original whois-information. Smarter ISPs will sub-allocate the range to the customer. This puts the customer in charge of their abuse complaints, rather than the ISP who doesn't really want to deal with the abuse complaints at all. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
opening up (exit policy) a bit ...
Let's say you run a tor relay with no exit policy: reject *:* And then later you alter that exit policy a bit: accept *:80,reject *:* My understanding is that this system will continue to be used as a non-exit relay, but will then also be used as an exit. That is, it's not going to be monopolized by exit traffic only ... it will do both, right ? If that is the case, is the distribution random ? Or is there some expected ratio I should see between non-exit relay traffic and port 80 exit traffic ? Have I complicated that ratio by having a very restrictive exit policy, or doesn't that matter ? Thank you. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Polipo question
does anyone know if there is a config file option to turn off all caching in Polipo? If you look at the Polipo manual, there's an index. If you look at the index, there's an entry for uncachable. If you follow the entry, you'll find the config variable uncachableFile. --jch *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: opening up (exit policy) a bit ...
On Sat, May 8, 2010 at 9:03 AM, John Case c...@sdf.lonestar.org wrote: Let's say you run a tor relay with no exit policy: reject *:* And then later you alter that exit policy a bit: accept *:80,reject *:* My understanding is that this system will continue to be used as a non-exit relay, but will then also be used as an exit. That is, it's not going to be monopolized by exit traffic only ... it will do both, right ? I don't believe this is correct. I think this means you're not an exit node at all. I suspect if you want your node to be an internal relay or have a chance at being a guard and still relay some exit traffic, you'll have more luck by running two tor instances, which could be on the same box. Put them in the same family (although I suppose tor will be smart enough to keep them from being used on the same circuit anyway, since they'll be on the same IP.) Then you can adjust the bandwidth for each instance to be the split you want. If you're willing to be an exit node, however, you'll help the tor network out most by doing 100% exit traffic. That's because we're currently constrained at the exits. Also consider letting port 443 through too. I do ports 80 and 443, and I haven't gotten an abuse complaint yet. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
RE: Polipo question
From: j...@pps.jussieu.fr To: or-talk@freehaven.net Subject: Re: Polipo question Date: Sat, 8 May 2010 18:08:22 +0200 does anyone know if there is a config file option to turn off all caching in Polipo? If you look at the Polipo manual, there's an index. If you look at the index, there's an entry for uncachable. If you follow the entry, you'll find the config variable uncachableFile. --jch Thank you, I have a recollection of reading that section and not really understanding it - I think I would need a good understanding of how caching works and all the directives first. From what I read, you have to know in advance which URLs you don't want cached, and put them in uncachableFile. That's not really practical. But thanks for trying to help. GD _ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
Re: opening up (exit policy) a bit ...
On May 8, 2010, at 7:54 PM, Dyno Tor wrote: On Sat, May 8, 2010 at 9:03 AM, John Case c...@sdf.lonestar.org wrote: Let's say you run a tor relay with no exit policy: reject *:* And then later you alter that exit policy a bit: accept *:80,reject *:* My understanding is that this system will continue to be used as a non-exit relay, but will then also be used as an exit. That is, it's not going to be monopolized by exit traffic only ... it will do both, right ? I don't believe this is correct. I think this means you're not an exit node at all. What do you mean, not an exit node at all? As long as the Tor process receives a HUP signal or is restarted to notify it of the config changes, it will become an exit. I suspect if you want your node to be an internal relay or have a chance at being a guard and still relay some exit traffic, you'll have more luck by running two tor instances, which could be on the same box. Put them in the same family (although I suppose tor will be smart enough to keep them from being used on the same circuit anyway, since they'll be on the same IP.) Then you can adjust the bandwidth for each instance to be the split you want. This is totally incorrect. Tor uses exit nodes in the middle and possibly even guard position, depending on flags and general scarcity of guards. If you're willing to be an exit node, however, you'll help the tor network out most by doing 100% exit traffic. That's because we're currently constrained at the exits. Also consider letting port 443 through too. I do ports 80 and 443, and I haven't gotten an abuse complaint yet. It is not possible to become a node that acts _only_ as exit. Sebastian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: opening up (exit policy) a bit ...
On Sat, May 8, 2010 at 1:56 PM, Sebastian Hahn m...@sebastianhahn.net wrote: On May 8, 2010, at 7:54 PM, Dyno Tor wrote: On Sat, May 8, 2010 at 9:03 AM, John Case c...@sdf.lonestar.org wrote: Let's say you run a tor relay with no exit policy: reject *:* And then later you alter that exit policy a bit: accept *:80,reject *:* My understanding is that this system will continue to be used as a non-exit relay, but will then also be used as an exit. That is, it's not going to be monopolized by exit traffic only ... it will do both, right ? I don't believe this is correct. I think this means you're not an exit node at all. What do you mean, not an exit node at all? As long as the Tor process receives a HUP signal or is restarted to notify it of the config changes, it will become an exit. Because he has reject *:* first, it won't even look at the commands later. First matching command wins. I suspect if you want your node to be an internal relay or have a chance at being a guard and still relay some exit traffic, you'll have more luck by running two tor instances, which could be on the same box. Put them in the same family (although I suppose tor will be smart enough to keep them from being used on the same circuit anyway, since they'll be on the same IP.) Then you can adjust the bandwidth for each instance to be the split you want. This is totally incorrect. Tor uses exit nodes in the middle and possibly even guard position, depending on flags and general scarcity of guards. Well, you definitely know better than I. I had been under the (false) impression that exit nodes were (at least mostly) used to exit. Why isn't that the case, given that we're constrained by exits? Or am I wrong about that too? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: opening up (exit policy) a bit ...
On Sat, 8 May 2010, Dyno Tor wrote: Let's say you run a tor relay with no exit policy: reject *:* And then later you alter that exit policy a bit: accept *:80,reject *:* (snip) What do you mean, not an exit node at all? As long as the Tor process receives a HUP signal or is restarted to notify it of the config changes, it will become an exit. Because he has reject *:* first, it won't even look at the commands later. First matching command wins. No, you misread the original - I am saying that I first have this exit policy: reject *:* and then I replace that exit policy with: accept *:80,reject *:* So I am indeed an exit... This is totally incorrect. Tor uses exit nodes in the middle and possibly even guard position, depending on flags and general scarcity of guards. Ok, that was the answer to my first question. My follow-up questions were: If that is the case, is the distribution random ? Or is there some expected ratio I should see between non-exit relay traffic and port 80 exit traffic ? Have I complicated that ratio by having a very restrictive exit policy, or doesn't that matter ? (FWIW, I picked port 80 just as an example) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: opening up (exit policy) a bit ...
No, you misread the original - I am saying that I first have this exit policy: reject *:* and then I replace that exit policy with: accept *:80,reject *:* So I am indeed an exit... Yup, I did misread it. Sorry! Back to lurking now... :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: opening up (exit policy) a bit ...
Thus spake John Case (c...@sdf.lonestar.org): So I am indeed an exit... This is totally incorrect. Tor uses exit nodes in the middle and possibly even guard position, depending on flags and general scarcity of guards. Ok, that was the answer to my first question. My follow-up questions were: If that is the case, is the distribution random ? Or is there some expected ratio I should see between non-exit relay traffic and port 80 exit traffic ? As of Tor 0.2.2.11-alpha, the ratios used by clients is listed in the consensus[1]*. See sections 3.2 and 3.4.3 of dir-spec.txt https://gitweb.torproject.org//tor.git?a=blob_plain;f=doc/spec/dir-spec.txt;hb=HEAD Have I complicated that ratio by having a very restrictive exit policy, or doesn't that matter ? (FWIW, I picked port 80 just as an example) You have, sort of. Because you do not exit to enough ports to get the 'Exit' flag, you will be treated as a middle or Guard-only node, depending upon your uptime. This means the following weights will apply to you in each of the three positions: Guard: Wgg (if you are a Guard, otherwise 0) Middle: Wmg (if you are a Guard, otherwise Wmm) Exit: Weg (if you are a Guard, otherwise Wem) In the current weight implementation we Handle bridges and strange exit policies: Wgm=Wgg, Wem=Wee, Weg=Wed This means that your non-Exit flagged node will be weighted like an Exit flagged node for the exit position, but will be weighted as if you were a non-scarce middle or guard node for the other positions. In sort, you would in theory get slightly more total load than if you were an actual Exit. As to the ratio of your exit to non-exit load, that depends heavily on if you have the Guard flag, if you are a Directory Mirror, what percentage of the exit traffic actually flows over port 80, and how many clients have upgraded to the new algorithm vs the old. *[1]. If there is a bug or other issue, these weights may be temporarily absent from the consensus. Currently, Bug 1294 is causing us to drop weights when there are no Guard+Exit flagged nodes, which can happen when Exits are scarce. When weights are absent, clients fall back to the previous client-based weighting algorithm. By not having an actual 'Exit' flag, you will be treated as a non-scarce Guard or middle node for purposes of this old algorithm too, and should see more load accordingly. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpBTg3WwcQ17.pgp Description: PGP signature
Re: opening up (exit policy) a bit ...
Thus spake Mike Perry (mikepe...@fscked.org): This means that your non-Exit flagged node will be weighted like an Exit flagged node for the exit position, but will be weighted as if you were a non-scarce middle or guard node for the other positions. In sort, you would in theory get slightly more total load than if you were an actual Exit. On second thought, this is not fully correct. You will in theory get slightly more load than if you were just a Guard/Middle node. Since we do not currently balance among different exit port classes, you might still get less load than a full-on Exit when Exits are scarce, because 80 might not carry that much traffic in terms of bytes as other ports. Not an easy question to answer in either case. Having good answers to these questions might help us refine our load balancing algoriths further. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpgktUvYXvIV.pgp Description: PGP signature
Re: opening up (exit policy) a bit ...
On Sat, 8 May 2010, Mike Perry wrote: This means that your non-Exit flagged node will be weighted like an Exit flagged node for the exit position, but will be weighted as if you were a non-scarce middle or guard node for the other positions. In sort, you would in theory get slightly more total load than if you were an actual Exit. On second thought, this is not fully correct. You will in theory get slightly more load than if you were just a Guard/Middle node. Since we do not currently balance among different exit port classes, you might still get less load than a full-on Exit when Exits are scarce, because 80 might not carry that much traffic in terms of bytes as other ports. Not an easy question to answer in either case. Having good answers to these questions might help us refine our load balancing algoriths further. Thanks. So, it's hard to say, but I can assume there will be significant exit traffic, even with just one TCP port valid for exit... I suppose I could see the ratio of actual connections by simply running 'netstat', yes ? If my orport and dirport are 9001/9030, and I am allowing port 80 exit, then all netstat connections showing port 80 are exit connections, so I could (roughly) calculate these numbers myself, right ? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: opening up (exit policy) a bit ...
Thus spake John Case (c...@sdf.lonestar.org): On Sat, 8 May 2010, Mike Perry wrote: This means that your non-Exit flagged node will be weighted like an Exit flagged node for the exit position, but will be weighted as if you were a non-scarce middle or guard node for the other positions. In sort, you would in theory get slightly more total load than if you were an actual Exit. On second thought, this is not fully correct. You will in theory get slightly more load than if you were just a Guard/Middle node. Since we do not currently balance among different exit port classes, you might still get less load than a full-on Exit when Exits are scarce, because 80 might not carry that much traffic in terms of bytes as other ports. Not an easy question to answer in either case. Having good answers to these questions might help us refine our load balancing algoriths further. Thanks. So, it's hard to say, but I can assume there will be significant exit traffic, even with just one TCP port valid for exit... I suppose I could see the ratio of actual connections by simply running 'netstat', yes ? If my orport and dirport are 9001/9030, and I am allowing port 80 exit, then all netstat connections showing port 80 are exit connections, so I could (roughly) calculate these numbers myself, right ? Yes. Though this brings up the other approxmiation of the load balancing algorithms, which is that we balance per-connection, which have non-uniform bandwidth use across ports and protocols. According to http://www.cs.washington.edu/homes/yoshi/papers/Tor/PETS2008_37.pdf, 92.5% of the connections through Tor are HTTP, accounting for 58% of the traffic. So you should see a much larger number of TCP connections (and possibly also total traffic) as comparted to if you also added port 443 and/or 6667 to gain the Exit flag. Especially if you are a Guard. The extra data that we would need beyond that published in the paper above is a data rate per connection by port, in addition to connection duration information. Gathering this data in a safe fashion, and figuring out how to use it are open questions (though probably not terribly difficult ones). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp5pRVfNmmWm.pgp Description: PGP signature
Re: opening up (exit policy) a bit ...
On Sat, 8 May 2010 22:49:26 + (UTC) John Case c...@sdf.lonestar.org On Sat, 8 May 2010, Mike Perry wrote: This means that your non-Exit flagged node will be weighted like an Exit flagged node for the exit position, but will be weighted as if you were a non-scarce middle or guard node for the other positions. In sort, you would in theory get slightly more total load than if you were an actual Exit. On second thought, this is not fully correct. You will in theory get slightly more load than if you were just a Guard/Middle node. Since we do not currently balance among different exit port classes, you might still get less load than a full-on Exit when Exits are scarce, because 80 might not carry that much traffic in terms of bytes as other ports. Not an easy question to answer in either case. Having good answers to these questions might help us refine our load balancing algoriths further. Thanks. So, it's hard to say, but I can assume there will be significant exit traffic, even with just one TCP port valid for exit... I suppose I could see the ratio of actual connections by simply running 'netstat', yes ? If my orport and dirport are 9001/9030, and I am allowing port 80 exit, then all netstat connections showing port 80 are exit connections, so I could (roughly) calculate these numbers myself, right ? No, not really. That method does not distinguish between connections going to actual web servers and connections going to other tor relays that listen on 80 as their ORPort or DirPort, of which there are quite a few. You would need to compare each address and port number with the addresses and port numbers listed in the directory to determine which case you were seeing. Also, netstat doesn't tell you whether your system connected to the other end or vice versa. pftop(8) does identify connections as being inbound (I) or outbound (O), but if you don't have pf(4) support on your system (OpenBSD and FreeBSD only, I think), then you don't have pftop available. I don't know what similar tools may be available for use with other systems. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: opening up (exit policy) a bit ...
On 5/8/2010 6:49 PM, John Case wrote: I suppose I could see the ratio of actual connections by simply running 'netstat', yes ? If my orport and dirport are 9001/9030, and I am allowing port 80 exit, then all netstat connections showing port 80 are exit connections, so I could (roughly) calculate these numbers myself, right ? They wouldn't only be exit connections, as many relays use 80/443 or other combinations of those ports for their orport and dirport, to be more accessible to users behind restrictive firewalls. So if you're a middle node or entry guard in a circuit you could still be making outgoing connections out to other nodes on those ports. But you'd probably get an acceptable approximation anyway. Regards, Tim *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
