Re: [tor-relays] new relays
I feel like you are SO missing the point. Making Tor block morally horrible things does not involve telling exit notes to block traffic to known porn sites. The porn sites with the boobies that someone might hit on port 80 on the public internet represent the Catholic Church of porn, metaphorically-speaking. The truly terrible stuff is hidden to where you as an exit node operator would never be able to simply block it by IP address or domain name. It seems clear that it would require designing into Tor the ability to inspect the content of its packets in the unencrypted form, plus be able to be configured to identify and reject files with certain identifiable signatures. This capability would have to be implemented in all nodes, in order to detect the reject-files should they come from the .onion sites. That kind of capability would damage Tor's anonymity at the technical level (/understate). If someone believes that making a G-rated Tor is a good idea, they must not be considering the wisdom behind why it was designed the way it was, with each node not knowing the nature of the data it passes. The same technical characteristics which protect the investigators and whistleblowers and rights of humanity will also by their nature protect the boobie-watchers. Think about this, understand this. It is not about the concept of anonymity and privacy, it's about the technical requirements necessary to provide it in the face of the hostile environment we have now. On Sunday 01/09/2013 at 5:48 pm, Jon Gardner wrote: On Aug 28, 2013, at 5:09 PM, Roger Dingledine a...@mit.edu wrote: On Tue, Aug 27, 2013 at 11:12:01PM +0200, Tor Exit wrote: Why is it so bad if a Tor exit operator tries to match the use of their node with their own moral beliefs? I really would like to support this if I could. I appreciate your kind and well-reasoned response, Roger. For those others who, through (unkind, often poorly spelled, and logically flawed) mockery and name-calling, hypocritically demanded censorship of the very idea that individual liberty necessarily involves individual moral responsibility, I have composed a poem. A few puerile punks would use Tor To browse for big boobs, nothing more Rights of humanity Was just false piety So bit by bit all the web closed the door. If you want to use Tor for immoral things, go ahead--it will obviously accommodate you--but please stop pretending to speak for those of us who run Tor nodes because we actually care about human rights and liberty, and aren't just using those nice catch-phrases as a cover for licentiousness and mindless self-gratification. You're a large part of the reason that Tor is technology non grata in so many places, to so many people that would otherwise fully support its mission. Hugs, Jon ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A bit more evidence on circuit creation storms
You could modify the tor init script to limit the memory usable by /usr/sbin/tor as described here: http://jlebar.com/2011/6/15/Limiting_the_amount_of_RAM_a_program_can_use.html But I don’t know if this works on RaspPi platform and what happens when the tor process hits the memory limit. Regards, Torland On Saturday 31 August 2013 11:14:04 Gordon Morehouse wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 krishna e bera: On 13-08-29 10:35 PM, Gordon Morehouse wrote: What on earth is causing so many circuit creation requests in such a short timespan? One possibility, if i recall correctly, is that the Tor that comes with the PirateBrowser bundle is configured to build single hop circuits. Make sure that these defaults are still set in your relay: The DDOS - because that's what it obviously is - managed to kill my Pi-based node last night, so I've finally restarted with all these except RefuseUnknownExits 1, just because of your caveat. I had some of the statistics already enabled, so it's continuing to collect those. Is there a way to give Tor a hard memory cap, so it won't chew up all available RAM on the system? AllowSingleHopExits 0 AllowSingleHopCircuits 0 You can also try RefuseUnknownExits 1but maybe auto is better And these may help sketch the circuit storms: EntryStatistics 1 ExitPortStatistics 1 ConnDirectionStatistics 1 Best, Gordon M. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJSIjJoAAoJED/jpRoe7/ujuicH/Au5NXr/q5MTYH54mPPuE/OJ 9jOkT/M34O0+U9gqYH8ja2gzTFf3CdxESraS6A7A+r2DWUX9R6l+zia5YX/SYCUu dWWNB843vXhcjNqhw01h05c70QgKStKrm6sLCjliVxhcovfMnkmMxLxk3EmQ3OzW nOdHQT2QGV+xCXqYz7FS9OtCnRmjTjI3bb8PJ1xcL76IjPGlCKr5vt7cDO3Y7x80 o0hnPJxMhYs0MhS5sNXfHIifDNT6LlCuZvIT0GLe3w9Gg15BUYKgn5bi1iNEtoSV J/2DbxvmT23Tv6E2WnpxEoOu/yupbHAiDcYbwIT1ig4mePA/xCgjdm7mEdqrXpE= =AiLg -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Pony CC
Ich checked both of my Exit nodes: IP Address 91.219.238.107 is listed in the CBL. It appears to be infected with a spam sending trojan, proxy or some other form of botnet. - uptime ~16 days IP Address 84.201.38.234 is not listed in the CBL. -- New node, uptime 24hrs This was detected by observing this IP attempting to make contact to a s_patcher Command and Control server, with contents unique to s_patcher CC command protocols. Not cool at all, let's see how the new node works out. I have been running a Tor exit node for only 2 days on a fresh IP address. However, that IP address is now blocked by spamhaus because it apparently tried to contact the Command and Control server of the pony malware: http://cbl.abuseat.org/lookup.cgi?ip=5.79.81.200 Other node operators, could you please try your IP address? Perhaps this could explain the recent increase in connections? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] onionoo
Been having a devil fo a time keeping my bridge up this week. One question: With the bridge up running, the map showing it connecting to circuits, why is onionoo reporting running:false, ? Should I worry about this discrepancy? Thanks, eliaz ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] onionoo
The usual deal is to just wait a bit more, until your bridge gets voted into the last consensus. The running: true/false field in Onionoo simply indicates whether your bridge/relay descriptor is listed in the last consensus (which is published every hour, and includes a list of relays and bridges which the network authorities agreed on being valid / etc. for client usage.) It usually takes some time (e.g. more than an hour) even after your bridge/relay is successfully running. At least that's my (perhaps oversimplifying) take. Perhaps you're using it yourself, but one of the ways to probe Onionoo in a user-friendly way is the new Globe tool [1]. It includes bridges as well as relays. [1]: http://globe.rndm.de/ -- Kostas. 0x0e5dce45 @ pgp.mit.edu ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] onionoo
On 9/2/2013 9:58 AM, Karsten Loesing wrote: On 9/2/13 3:52 PM, eliaz wrote: Been having a devil fo a time keeping my bridge up this week. One question: With the bridge up running, the map showing it connecting to circuits, why is onionoo reporting running:false, ? Should I worry about this discrepancy? Thanks, eliaz Can you post the hashed fingerprint here? Happy to take a look. B68A205B1C4D8AACE4AE83CF15B31FCD140373F5 But don't knock yourself out tracking it. onionoo is showing true now. Usually it's quite fast, and part of the reason for the recent slowness may have been that I was having trouble with port forwarding (local issues, not worth recounting here) was loading unloading tor to fix it. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] onionoo
On 9/2/2013 10:02 AM, Kostas Jakeliunas wrote: The usual deal is to just wait a bit more, until your bridge gets voted into the last consensus. The running: true/false field in Onionoo simply indicates whether your bridge/relay descriptor is listed in the last consensus (which is published every hour, and includes a list of relays and bridges which the network authorities agreed on being valid / etc. for client usage.) It usually takes some time (e.g. more than an hour) even after your bridge/relay is successfully running. At least that's my (perhaps oversimplifying) take. Thanks, you're right. Perhaps you're using it yourself, but one of the ways to probe Onionoo in a user-friendly way is the new Globe tool [1]. It includes bridges as well as relays. [1]: http://globe.rndm.de/ Thanks for the pointer, globe is interesting. What is the latency of globe (and the browser bundle map, for that matter)? I've assumed that the circuits shown on the map are high-consensus, but I haven't been able to correlate globe's top 10 with relays shown on the map. Maybe I'm being impatient here too? eliaz gpg: 0x63D01EC6 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A bit more evidence on circuit creation storms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 tor-admin: You could modify the tor init script to limit the memory usable by /usr/sbin/tor as described here: http://jlebar.com/2011/6/15/Limiting_the_amount_of_RAM_a_program_can_use.html But I don’t know if this works on RaspPi platform and what happens when the tor process hits the memory limit. Thank you, I may mess around with this - what I'd dearly prefer is a torrc setting though. Maybe I should search for existing feature requests and/or submit a new one. [snip] Is there a way to give Tor a hard memory cap, so it won't chew up all available RAM on the system? Best, - -Gordon M. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJSJMWtAAoJED/jpRoe7/ujEQAIAKWnkP3OfemDbxcmhJJr/rIW 65Hpa8gQl9S5z1OoQXLKHEnlIziYj8UJbWM2+ADsJJReAHtWSMAb8ZL7MLSn5wR8 hoTtsQJ+ZjXPP0M0Yiqgwb2HRUcWYuarGOseLzWUwsBAy3g0ucsDrnDhwj9cGPdB AAa4g4JJ/k5jW1N8clS0WIVJLnzDs4xYbxZzaLc54yQqawS4bybJUqjghLQekVdo wETMVK4Ajoip2Le1gDGevcO+0a6Nl15QLNdIkGSY7n8vRjQ1gvNpMIDt2CM+miko lwiWMy4OMbEQkDqKN7nkR15gLDoHsjgp37EbJn5im5Nfp/aNGMNGj8bWv0oi8Is= =G9Rh -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] node list or moral discussion forum
On Mon, Sep 02, 2013 at 08:33:48AM -0400, That Guy wrote: a suggestion: maybe a new tor-node-moralfag-mailinglist should be set-up as to remove this soap opera from a technical mailing list. Eugh, please don't use homophobic language like whateverfag. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Unsub me please?
Thank you. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unsub me please?
Hi, Am 2013-09-02 19:17, schrieb Susan Harbison: Thank you. Please follow the link in the signature of this mail. On the bottom of this page you find instructions about how to unsubscribe yourself from the list. Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unsub me please?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02.09.2013 19:17, Susan Harbison wrote: Thank you. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Hello Susan, you can easily do it yourself by visiting [1] and filling in your mail adress at the bottom of the page. Regards Martin [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJMiqAAoJEM1jnLOhksr3CdIQAKlXiDsz34b3YaSVi9jnIWZg 0MntPRrZsnwQII+oYrjFYmvf2Bbi9W8W72gvUJQRcowmb7jEj9yanQJt64owCv26 BNrv/2nhLYwilQly0hcwV/mZGaXMxtcPT92oRZaQOHYfoCRVdlDpJCn+OC9i+3S1 0amSUQGekfqtCcXHg0or3zRP3kRfvi8q/Bd7XhEmtjnFqNYqoFjvA7G9oXeH5RUY R7OOk0tNihQKnv/3lU6L9+S3UZ57IkmfCyV01oT3KtHxn/F6pIsBvRiv0AbEPTOI ZELLDeulgln2Zo8uM1TwCFqEw/gcGrV0vqk7hs4r3Pgwt7OPuY2ryJuNZhFpQZLA azJHJUnhiFar3kHcVYFznnOTQRt1llLtBg/7+62eRPFNx9qOI+njy6DfQ+3JekuL gV2QLhLExZktXYTskZte1NSlI9tNT2hrtQQkgm2Qdh5yF9kV8pvKyQTfWmsA7Aix pKa0j1ybDnlJiMvoSG/iytXnszccT1JnX91vxDVBn2WNO5nRI5drjdErVfJg6oou EGWg+hJ2zUUcCPQG41ca4sj7ahMX2rrux/2ibacAjhdBtlqw3YO70+CmW/7aFBMS zGM3lLGn26dTBtGvXIYMxOsImTCkLsldpTdl8nxdRipTEJah9U5DgozNgFfGZWf9 AGRrWEr5ZMGQx7Ux10B5 =B76R -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Status of UserspaceIOCPBuffers ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 So in the documentation: UserspaceIOCPBuffers 0|1 If IOCP is enabled (see DisableIOCP above), setting this option to 1 will tell Tor to disable kernel-space TCP buffers, in order to avoid needless copy operations and try not to run out of non-paged RAM. This feature is experimental; don’t use it yet unless you’re eager to help tracking down bugs. (Default: 0) Is this description still accurate, or is it better debugged nowadays? Would this be useful to set on machines with limited memory resources, e.g. the Raspberry Pi? Thanks much for any insight. - -Gordon M. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJSJMrDAAoJED/jpRoe7/ujZX8IALXnFOs6WEQsud4UChnjdDRC Cor6LScDdXjGBvRDodMxyrF6lX50SwIaBR+zu4I4Hw2ekit8UZdBdZafWSjQgq5W KdMW1XruYBEIN2OcWSjSoZ1K2DzuOr1O77JwBhCuRcJtqqIP5yfD2TcF6AmuxHWk 82is5XCppem1b3CVobduKIVvbC6vUu+3fau5jkwrRv0xVQGTEtSWRY9TDFP5hoxB cZN+N2yYAm0pZ9+X1fFOHteKOx9r8ENsHfSCeZfKJXbbeRmklxVnZ1k3AgU2BiET L2tVs/piMOkhOd/hGX59bRk/IyvxArmXxd5+Vq9ejLZa7nmKMuOfZYbKdGo+zlE= =b1Os -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] node list or moral discussion forum
On Mon, 02 Sep 2013 21:39:35 +, Yoriz wrote: That Guy wrote: to remove this soap opera from a technical mailing list. Soap opera? Apparently you are missing the point. The soap opera was the part where someone tried to filter tor traffic on moral grounds which is obviously not feasible. Obviously malware writers will use Tor for various purposes, but connecting to a CC via Tor would not make sense since they have the largest anonymising botnet themselves. It would still be the question what the botnet is for - anonymization isn't usually the goal. Using a hidden service for CC access gets you around all the stuff with fastflux deployment. Which in turn makes me wonder: How much code change and deployment would it take to take down (as in 'make inaccessible via the tor network') a given hidden service? Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Pony CC
hi, xoroxDE2 176.9.122.78 *is listed * http://cbl.abuseat.org/lookup.cgi?ip=176.9.122.78.pubmit=Lookup xoroxFR 5.135.167.214 *is listed * http://cbl.abuseat.org/lookup.cgi?ip=5.135.167.214.pubmit=Lookup xoroxLU 94.242.252.225 *is listed * http://cbl.abuseat.org/lookup.cgi?ip=94.242.252.225.pubmit=Lookup xoroxDE xoroxLU2 are not listed ... :-) -- xorox5...@gmail.com +32/496.702.589 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Analysis of log file
Hej,
Reporting that message is on my two exit relays running for just one day.
Robert
Hi tor-relay list,
I have been running a tor node for 133 days and Im starting to receive
some weird messages in the log file. One of them look like this:
Received http status code 504 (Gateway Time-out) from server
'154.35.32.5:80' while fetching
/tor/server/d/9169637E422C216BECD05C6CFE3AE.
I also have another one which appear regular:
[warn] {NET} Failing because we have 991 connections already. Please
raise your ulimit -n.
First question is: any ideas how to get ride of these messages ? Second:
Would it be possible to submit a log file for further analysis, and to
whom should I send it ?
The node is running on ARM debian box. I can of cause provide details if
it necessary.
Best regards
Carsten Larsen
Fingerprint: E1EE4FB010F28E55B7ACA2D046AB89F3B413F2A3
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and
family!
Visit http://www.inbox.com/photosharing to find out more!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Analysis of log file
I have been running a tor node for 133 days and Im starting to receive some weird messages in the log file. One of them look like this: Received http status code 504 (Gateway Time-out) from server '154.35.32.5:80' while fetching /tor/server/d/9169637E422C216BECD05C6CFE3AE. https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Hi Carsten, that is being caused by some ongoing issues with one of the directory authorities (Faravahar). I contacted the authority operator a little while ago and he's presently looking into it. Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] onionoo
On 9/2/2013 11:59 AM, Steve Snyder wrote: On 09/02/2013 10:02 AM, Kostas Jakeliunas wrote: [1]: http://globe.rndm.de/ Having this tool on an unencrypted HTTP site doesn't seem safe to me. Anybody can sniff the bridge IP addresses that users submit for reporting. It may be different if someone compiles the program locally, but AFAICT no secrets are being divulged from the globe web page. From the page the details of no bridge can be found without knowing the name of the bridge in the first place; and if someone knows that she also know the other details. One doesn't have to go to the page to do a brute force attack. At the same time globe is useful in helping lower-level bridge operators such as myself get a better sense of what the information windows in the browser bundle are actually telling us. If I'm wrong in any of the above, please do correct me. eliaz gpg: 0x63D01EC6 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
