- tor-relays - lists.torproject.org

Massive ongoing google groups spamming
by tor-admin 13 Sep '12

13 Sep '12

Hi all, there is a massive spamming of google groups ongoing. I received several complains as below. From the domain list it seems that all major Tor exit nodes are affected. Running an Exit without custom WHOIS, all abuse message are received by my ISP and forwarded. So I have to temporarily ban google groups. How do other operators deal with this? Regards, Torland "This is some voluminous, off-topic flooding and harassment on the ba.broadcast Usenet newsgroup. It is being reported to abuse reporting mailboxes based on the contents of the NNTP-Posting-Host: and X-Complaints-To: headers, and lookup of the originating IP address via WHOIS and the Network Abuse Clearinghouse. They are sometimes also crossposted to unrelated newsgroups such as rec.arts.tv, soc.culture.new-zealand, and several other newsgroups in the nz.* hierarchy. It is disruptive, and completely off-topic, as well as causing disruptive, cascaded flame wars among those unrelated newsgroups. This user has also been posting from other sources, including 100tb.com, 51.net, 62.net, all.de, bahnhof.se, bayern.de, boingboing.net, broadviewnet.net, ccc.de, formlessnetworking.net, hessmo.com, noisetor.net, oceanic.net, plebia.org, privacyrepublic.org, riseup.net, ru.is, sbcglobal.net, servers.com, snydernet.net, solidonetworks.com, stanford.edu, stargrave.org, torland.me, torservers.net, dmzglobal.com, telstraclear.net, xtra.co.nz, clear.net.nz, orcon.net.nz, netgate.net.nz, freeparking.co.nz, powerusenet.com, giganews.com, thundernews.com, altopia.com, comcast.net, groups.google.com, and tigerusenet.com. It appears that you are merely the latest of his victims. The charter of ba.broadcast is as follows: "This group is here for discussions, comments and program reminders about broadcast media in the San Francisco Bay Area, both radio and television. It also includes cable systems and TVRO/BCRO in the SF Bay Area. It does not include scanner, ham radio or other action here in the SF Bay Area; these may be addressed in another newsgroup at another time. Issues of national interest should be posted to one of the groups in rec.arts.tv or rec.radio." (see: http://groups.google.com/group/ba.broadcast/browse_thread/thread/ddfbd8175e…) The charter does not include sexual innuendo and libel, abusive threats, bigotry and minority bashing, or any off-topic discussion of subjects not reasonably related to broadcasting in the Bay Area, which now consitute the overwhelming majority of current message traffic on ba.broadcast, to the detriment and exclusion of on-topic participation by others. Please take appropriate action to put a stop this this misbehavior originating from your site that is disrupting ba.broadcast. [... Offending article removed ...]

3 2

Re: [tor-relays] tor-relays Digest, Vol 18, Issue 1
by Christian 13 Sep '12

13 Sep '12

Hi Roger, > Who owns that socket file? /var/run/tor/control is owned by debian-tor. > Anything else in that other default config file? The tor-service-defaults-torrc file contains: DataDirectory /var/lib/tor PidFile /var/run/tor/tor.pid RunAsDaemon 1 User debian-tor ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie Log notice file /var/log/tor/log > > ORPort 443 NoListen > > > ORPort 0.0.0.0:9090 NoAdvertise > > > ORPort [::]:9090 IPv6Only NoAdvertise > > > > Is this ipv6 bind attempt the one causing problems? > > > > The ipv6 bind attempt was a try to solve the problem. Problem persists with and without ipv6 bind attempt. Thanks a lot! christian > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Failed to parse/validate config: failed to bind one of the > listener ports (Christian) > 2. Re: Failed to parse/validate config: failed to bind one of > the listener ports (Roger Dingledine) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 01 Jul 2012 06:14:19 +0200 > From: Christian <brightsidedarkside(a)t-online.de> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] Failed to parse/validate config: failed to bind > one of the listener ports > Message-ID: <1341116059.2767.42.camel(a)delusions.local> > Content-Type: text/plain; charset="UTF-8" > > Hi Nick, hi Jean, > > thanks a lot for your fast reaction. I was at my parents' place for a > week, that's why I'm a little late. > > First, I tried port 9001, but in fact it is a port forwarding on the > router from 443 to 9090. > > Following, I post the terminal output when using the given torrc and the > torrc file itself. > Really, no logs are created, independent of the logging options. > The socket unlink issue happens since I use tor and that's for a while > now - it never affected functionality. > Yes, I'm into psychiatric symptoms. A friend of mine uses monsters' > names from films. ;-) > > Again, thanks a lot for your help! > > Thankfully > > christian > > ca@delusions:~$ sudo service tor restart > [sudo] password for ca: > * Stopping tor daemon... > [ OK ] > * Starting tor > daemon... > Jul 01 06:00:13.321 [warn] Could not unlink /var/run/tor/control: > Permission denied > Jul 01 06:00:13.321 [warn] Failed to parse/validate config: Failed to > bind one of the listener ports. > Jul 01 06:00:13.321 [err] Reading config failed--see warnings above. > > [fail] > ca@delusions:~$ > > > > The torrc (complete to prevent me from confusing, but slightly spoiled > by my mail client with line breaks - RunAsDeamon is set by another > default config file): > > > ## Configuration file for a typical Tor user > ## Last updated 22 April 2012 for Tor 0.2.3.14-alpha. > ## (may or may not work for much older or much newer versions of Tor.) > ## > ## Lines that begin with "## " try to explain what's going on. Lines > ## that begin with just "#" are disabled commands: you can enable them > ## by removing the "#" symbol. > ## > ## See 'man tor', or https://www.torproject.org/docs/tor-manual.html, > ## for more options you can use in this file. > ## > ## Tor will look for this file in various places based on your platform: > ## https://www.torproject.org/docs/faq#torrc > > ## Tor opens a socks proxy on port 9050 by default -- even if you don't > ## configure one below. Set "SocksPort 0" if you plan to run Tor only > ## as a relay, and not make any local application connections yourself. > #SocksPort 9050 # Default: Bind to localhost:9050 for local connections. > #SocksPort 192.168.0.1:9100 # Bind to this adddress:port too. > > ## Entry policies to allow/deny SOCKS requests based on IP address. > ## First entry that matches wins. If no SocksPolicy is set, we accept > ## all (and only) requests that reach a SocksPort. Untrusted users who > ## can access your SocksPort may be able to learn about the connections > ## you make. > #SocksPolicy accept 192.168.0.0/16 > #SocksPolicy reject * > > ## Logs go to stdout at level "notice" unless redirected by something > ## else, like one of the below lines. You can have as many Log lines as > ## you want. > ## > ## We advise using "notice" in most cases, since anything more verbose > ## may provide sensitive information to an attacker who obtains the > logs. > ## > ## Send all messages of level 'notice' or higher > to /var/log/tor/notices.log > #Log notice file /var/log/tor/notices.log > ## Send every possible message to /var/log/tor/debug.log > Log debug file /var/log/tor/debug.log > ## Use the system log instead of Tor's logfiles > #Log notice syslog > ## To send all messages to stderr: > #Log debug stderr > > ## Uncomment this to start the process in the background... or use > ## --runasdaemon 1 on the command line. This is ignored on Windows; > ## see the FAQ entry if you want Tor to run as an NT service. > #RunAsDaemon 1 > > ## The directory for keeping all the keys/etc. By default, we store > ## things in $HOME/.tor on Unix, and in Application Data\tor on Windows. > #DataDirectory /var/lib/tor > > ## The port on which Tor will listen for local connections from Tor > ## controller applications, as documented in control-spec.txt. > #ControlPort 9051 > ## If you enable the controlport, be sure to enable one of these > ## authentication methods, to prevent attackers from accessing it. > #HashedControlPassword > 16:872860B76453A77D60CA2BB8C1A7042072093276A3D701AD684053EC4C > #CookieAuthentication 1 > > ############### This section is just for location-hidden services ### > > ## Once you have configured a hidden service, you can look at the > ## contents of the file ".../hidden_service/hostname" for the address > ## to tell people. > ## > ## HiddenServicePort x y:z says to redirect requests on port x to the > ## address y:z. > > #HiddenServiceDir /var/lib/tor/hidden_service/ > #HiddenServicePort 80 127.0.0.1:80 > > #HiddenServiceDir /var/lib/tor/other_hidden_service/ > #HiddenServicePort 80 127.0.0.1:80 > #HiddenServicePort 22 127.0.0.1:22 > > ################ This section is just for relays ##################### > # > ## See https://www.torproject.org/docs/tor-doc-relay for details. > > ## Required: what port to advertise for incoming Tor connections. > #ORPort 443 > ## If you want to listen on a port other than the one advertised in > ## ORPort (e.g. to advertise 443 but bind to 9090), you can do it as > ## follows. You'll need to do ipchains or other port forwarding > ## yourself to make this work. > ORPort 443 NoListen > ORPort 0.0.0.0:9090 NoAdvertise > ORPort [::]:9090 IPv6Only NoAdvertise > > ## The IP address or full DNS name for incoming connections to your > ## relay. Leave commented out and Tor will guess. > #Address noname.example.com > > ## If you have multiple network interfaces, you can specify one for > ## outgoing traffic to use. > # OutboundBindAddress 10.0.0.5 > > ## A handle for your relay, so people don't have to refer to it by key. > Nickname BrightSideDarkSide > > ## Define these to limit how much relayed traffic you will allow. Your > ## own traffic is still unthrottled. Note that RelayBandwidthRate must > ## be at least 20 KB. > ## Note that units for these config options are bytes per second, not > bits > ## per second, and that prefixes are binary prefixes, i.e. 2^10, 2^20, > etc. > #RelayBandwidthRate 100 KB # Throttle traffic to 100KB/s (800Kbps) > #RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps) > > ## Use these to restrict the maximum traffic per day, week, or month. > ## Note that this threshold applies separately to sent and received > bytes, > ## not to their sum: setting "4 GB" may allow up to 8 GB total before > ## hibernating. > ## > ## Set a maximum of 4 gigabytes each way per period. > #AccountingMax 4 GB > ## Each period starts daily at midnight (AccountingMax is per day) > #AccountingStart day 00:00 > ## Each period starts on the 3rd of the month at 15:00 (AccountingMax > ## is per month) > #AccountingStart month 3 15:00 > > ## Contact info to be published in the directory, so we can contact you > ## if your relay is misconfigured or something else goes wrong. Google > ## indexes this, so spammers might also collect it. > ContactInfo Sides of the moon <brightsidedarkside AT t-online dot de> > ## You might also include your PGP or GPG fingerprint if you have one: > #ContactInfo 0xFFFFFFFF Random Person <nobody AT example dot com> > > ## Uncomment this to mirror directory information for others. Please do > ## if you have enough bandwidth. > #DirPort 9030 # what port to advertise for directory connections > ## If you want to listen on a port other than the one advertised in > ## DirPort (e.g. to advertise 80 but bind to 9091), you can do it as > ## follows. below too. You'll need to do ipchains or other port > ## forwarding yourself to make this work. > #DirPort 80 NoListen > #DirPort 127.0.0.1:9091 NoAdvertise > ## Uncomment to return an arbitrary blob of html on your DirPort. Now > you > ## can explain what Tor is if anybody wonders why your IP address is > ## contacting them. See contrib/tor-exit-notice.html in Tor's source > ## distribution for a sample. > #DirPortFrontPage /etc/tor/tor-exit-notice.html > > ## Uncomment this if you run more than one Tor relay, and add the > identity > ## key fingerprint of each Tor relay you control, even if they're on > ## different networks. You declare it here so Tor clients can avoid > ## using more than one of your relays in a single circuit. See > ## https://www.torproject.org/docs/faq#MultipleRelays > ## However, you should never include a bridge's fingerprint here, as it > would > ## break its concealability and potentionally reveal its IP/TCP address. > #MyFamily $keyid,$keyid,... > > ## A comma-separated list of exit policies. They're considered first > ## to last, and the first match wins. If you want to _replace_ > ## the default exit policy, end this with either a reject *:* or an > ## accept *:*. Otherwise, you're _augmenting_ (prepending to) the > ## default exit policy. Leave commented to just use the default, which > is > ## described in the man page or at > ## https://www.torproject.org/documentation.html > ## > ## Look at https://www.torproject.org/faq-abuse.html#TypicalAbuses > ## for issues you might encounter if you use the default exit policy. > ## > ## If certain IPs and ports are blocked externally, e.g. by your > firewall, > ## you should update your exit policy to reflect this -- otherwise Tor > ## users will be told that those destinations are down. > ## > ## For security, by default Tor rejects connections to private (local) > ## networks, including to your public IP address. See the man page entry > ## for ExitPolicyRejectPrivate if you want to allow "exit enclaving". > ## > #ExitPolicy accept *:6660-6667,reject *:* # allow irc ports but no more > #ExitPolicy accept *:119 # accept nntp as well as default exit policy > ExitPolicy reject *:* # no exits allowed > > ## Bridge relays (or "bridges") are Tor relays that aren't listed in the > ## main directory. Since there is no complete public list of them, even > an > ## ISP that filters connections to all the known Tor relays probably > ## won't be able to block all the bridges. Also, websites won't treat > you > ## differently because they won't know you're running Tor. If you can > ## be a real relay, please do; but if not, be a bridge! > BridgeRelay 1 > ## By default, Tor will advertise your bridge to users through various > ## mechanisms like https://bridges.torproject.org/. If you want to run > ## a private bridge, for example because you'll give out your bridge > ## address manually to your friends, uncomment this line: > #PublishServerDescriptor 0 > > User debian-tor > > > > tor-relays-request(a)lists.torproject.org: > > Send tor-relays mailing list submissions to > > tor-relays(a)lists.torproject.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > or, via email, send a message with subject or body 'help' to > > tor-relays-request(a)lists.torproject.org > > > > You can reach the person managing the list at > > tor-relays-owner(a)lists.torproject.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of tor-relays digest..." > > > > > > Today's Topics: > > > > 1. Re: Failed to parse/validate config: failed to bind one of > > the listener ports (Nick Mathewson) > > 2. Re: Failed to parse/validate config: failed to bind one of > > the listener ports (Jean Trolleur) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 26 Jun 2012 11:59:22 -0400 > > From: Nick Mathewson <nickm(a)freehaven.net> > > To: tor-relays(a)lists.torproject.org > > Subject: Re: [tor-relays] Failed to parse/validate config: failed to > > bind one of the listener ports > > Message-ID: > > <CAKDKvuyeEBDEO6rrbqVQSZcOy_cbeuGWMX2gisUjjETk0VgJEw(a)mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On Sat, Jun 23, 2012 at 7:38 PM, Christian > > <brightsidedarkside(a)t-online.de> wrote: > > > Hi dear fellows, > > > > > > I'm sorry to use again this way of addressing my problem as in Vol 17, > > > Issue 5. It will be the last time. Promise. > > > > > > I can't find any solution on the web. > > > When starting tor, it always reads "Failed to parse/validate config: > > > failed to bind one of the listener ports". > > > > Hm. It really should be saying something more than that on startup; > > there should be a message right before that about *why* it couldn't > > parse or validate the ports. > > > > I just tried the ORPort combination you listed there, and it seemed to > > work out okay for me. It might be easier to diagnose if you could > > upload your entire torrc, and the entire output of starting Tor up to > > the point where it says "failed to parse/validate config:" > > > > hth, > > -- > > Nick > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 26 Jun 2012 15:18:42 -0500 > > From: Jean Trolleur <sigtstp(a)gmail.com> > > To: tor-relays(a)lists.torproject.org > > Subject: Re: [tor-relays] Failed to parse/validate config: failed to > > bind one of the listener ports > > Message-ID: > > <CAPN5qOdaMr==8D-kTz01cAZDHrDXSGuh5T+3DVfscJLx8jLgZA(a)mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Try: > > > > ORPort 443 > > ORListenAddress 0.0.0.0:9001 > > > > On Sat, Jun 23, 2012 at 6:38 PM, Christian > > <brightsidedarkside(a)t-online.de> wrote: > > > Hi dear fellows, > > > > > > I'm sorry to use again this way of addressing my problem as in Vol 17, > > > Issue 5. It will be the last time. Promise. > > > > > > I can't find any solution on the web. > > > When starting tor, it always reads "Failed to parse/validate config: > > > failed to bind one of the listener ports". > > > > > > Furthermore, there are only empty logfiles, independent of the > > > configuration of the logs option "notice". > > > > > > Has anyone else this kind of problem? > > > > > > This is my ORPort section: > > > ORPort 443 NoListen > > > ORPort 0.0.0.0:9090 NoAdvertise > > > > > > I even can't make a control port accessible for e.g. arm running on the > > > same machine, although I didn't use it before. > > > > > > Client functionality is not working either. No connections through tor. > > > > > > Tor is configured as a bridge, my OS is Ubuntu lucid 10.04 and Tor's > > > version is 2.3.17-beta-1~lucid+1. > > > > > > It just worked until the upgrade to the new version through torproject's > > > repository. > > > > > > I really do have forwarded external port 443 to port 9090 on my machine. > > > > > > It nearly has me left in broken state dying. > > > > > > I checked for new requests concerning apparmor allowance, but there were > > > only the ability to chown and access to /sys/devices/system/cpu/ which I > > > granted both. > > > > > > I'm not so really competent with computers and therefore grateful for > > > any help. > > > Strange. No error logs, no function, no topic on the web.. > > > > > > Kind regards, > > > > > > christian > > > > > > > > > _______________________________________________ > > > tor-relays mailing list > > > tor-relays(a)lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > ------------------------------ > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > End of tor-relays Digest, Vol 17, Issue 8 > > ***************************************** > > > > > ------------------------------ > > Message: 2 > Date: Sun, 1 Jul 2012 05:14:22 -0400 > From: Roger Dingledine <arma(a)mit.edu> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Failed to parse/validate config: failed to > bind one of the listener ports > Message-ID: <20120701091422.GB8804(a)moria.seul.org> > Content-Type: text/plain; charset=us-ascii > > On Sun, Jul 01, 2012 at 06:14:19AM +0200, Christian wrote: > > Really, no logs are created, independent of the logging options. > > That's expected -- it's because logs are parsed in the same step as > binding the sockets, and it never gets to the 'setting up the logs' part. > > > The socket unlink issue happens since I use tor and that's for a while > > now - it never affected functionality. > > Who owns that socket file? > > > The torrc (complete to prevent me from confusing, but slightly spoiled > > by my mail client with line breaks - RunAsDeamon is set by another > > default config file): > > Anything else in that other default config file? > > > ORPort 443 NoListen > > ORPort 0.0.0.0:9090 NoAdvertise > > ORPort [::]:9090 IPv6Only NoAdvertise > > Is this ipv6 bind attempt the one causing problems? > > --Roger > > > > ------------------------------ > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > End of tor-relays Digest, Vol 18, Issue 1 > *****************************************

1 1

[OT] ExcludeNodes no longer working
by Scott Bennett 12 Sep '12

12 Sep '12

I know this really belongs on tor-talk, but I haven't been subscribed to it for a long time now. Sorry if posting this here bothers anyone. Back in early July, I upgraded from 0.2.3.13-alpha to 0.2.3.18-rc. I immediately ran into problems with a python script that honors the http_proxy environment variable, which I normally have set to the localhost port for privoxy, which, in turn, connects to tor's SOCKS port. I couldn't really see what was going wrong, but using arm to ask for a new identity seemed to help sometimes to get a circuit that worked. Sending tor a SIGHUP instead also seemed to work about as often. A bit over a week ago, I switched to 0.2.3.20-rc, and the problem still occurs. However, 0.2.3.20-rc now also emits a new message from time to time, the most recent occurrence of which is Sep 06 06:02:45.934 [notice] Low circuit success rate 7/21 for guard TORy0=753E0B5922E34BF98F0D21CC08EA7D1ADEEE2F6B. Wondering whether such circuit-building failures might be related to the other problem, I began a little experiment: each time I saw a "Low circuit success rate" message, I added the key fingerprint of the node in question to my ExcludeNodes list in torrc and sent tor a SIGHUP. The problem is still occurring, though, and when I look at the circuits involved, they all seem to have at least one of the excluded nodes in them, usually in the entry position. So my question is, what changed between 0.2.3.13-alpha and 0.2.3.18-rc (or possibly 0.2.3.20-rc) in the handling of nodes listed in the ExcludeNodes line in torrc? And is there anything I can do to get the ExcludeNodes list to work again the way it used to work? Thanks in advance for any relevant information. 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 * **********************************************************************

5 8

Re: [tor-relays] [OT] ExcludeNodes no longer working
by Scott Bennett 12 Sep '12

12 Sep '12

On Tue, 11 Sep 2012 16:24:36 -0400 Nick Mathewson <nickm(a)freehaven.net> wrote: >On Tue, Sep 11, 2012 at 1:12 PM, Jacob Appelbaum <jacob(a)appelbaum.net> wrote: >> Hi Scott, >> >> It is nice to see you posting again, I had wondered where you had gone. >> >> Scott Bennett: >>> I know this really belongs on tor-talk, but I haven't been subscribed >>> to it for a long time now. Sorry if posting this here bothers anyone. >> >> >> Seems like a fine place to discuss relay problems, which is what it >> sounds like, no? > >Maaybe! The very best place would be the bugtracker, of course. (I do >seem to recall that you have some issues with trac -- I'm just >mentioning the bugtracker so that other people don't get the idea that >the mailing lists are the best place for bug reports. But a bug >report on the mailing list is much much better than no bug report at >all.) You switched trackers a year or two ago. I don't recall whether I've tried the new one. Either way, I hesitate to submit a bug report until I'm pretty sure I'm looking at a bug, which is why I asked on this list whether anyone else could suggest anything. > >>> Back in early July, I upgraded from 0.2.3.13-alpha to 0.2.3.18-rc. >>> I immediately ran into problems with a python script that honors the >>> http_proxy environment variable, which I normally have set to the localhost >>> port for privoxy, which, in turn, connects to tor's SOCKS port. I couldn't >>> really see what was going wrong, but using arm to ask for a new identity >>> seemed to help sometimes to get a circuit that worked. Sending tor a >>> SIGHUP instead also seemed to work about as often. >> >> If you use 0.2.2.x - what happens? > >I'm not sure what the bug described here is, fwiw. What is the >behavior for the circuits that don't work, and to what extent is >0.2.2.x better? The problem is that the python script in question often has no trouble, but also often does. When it does, it usually gets a good connection twice and fails on the third connection. (Or at least I *think* that's what it does.) Then I either ask tor nicely with arm for a new set of circuits or I pound on tor with a SIGHUP for same, and then try the python script again. The process is slow, so it's very irritating to have to babysit it repeatedly until it finally gets a good connection. If I've left the script a small list of work to do, the failure may come at any point in the list, which then terminates the script. :-( I think it may have an option to ignore errors, but I don't really see an option like that as being very helpful in this situation because it would just fail its way through the rest of the list from that point, but it would take a long time to do that. Quitting outright is much faster. > >>> A bit over a week ago, I switched to 0.2.3.20-rc, and the problem >>> still occurs. However, 0.2.3.20-rc now also emits a new message from time >>> to time, the most recent occurrence of which is >>> >>> Sep 06 06:02:45.934 [notice] Low circuit success rate 7/21 for guard TORy0=753E0B5922E34BF98F0D21CC08EA7D1ADEEE2F6B. >>> >> >> That is an interesting message - I wonder if the author of that message >> might chime in? > >Looks like bug #6475. > >>> Wondering whether such circuit-building failures might be related to the >>> other problem, I began a little experiment: each time I saw a "Low circuit >>> success rate" message, I added the key fingerprint of the node in question >>> to my ExcludeNodes list in torrc and sent tor a SIGHUP. >>> The problem is still occurring, though, and when I look at the >>> circuits involved, they all seem to have at least one of the excluded >>> nodes in them, usually in the entry position. So my question is, what >>> changed between 0.2.3.13-alpha and 0.2.3.18-rc (or possibly 0.2.3.20-rc) >>> in the handling of nodes listed in the ExcludeNodes line in torrc? And >>> is there anything I can do to get the ExcludeNodes list to work again >>> the way it used to work? >>> Thanks in advance for any relevant information. >>> >> >> It seems that there are two issues - one is that a guard is failing to >> build circuits, the other is that you can't seem to exclude them. I have >> to admit, I'm more interested in the former... Is there a pattern to the >> failures? That is for the 7 successes for that node, did you see >> anything interesting? Were say, the nodes that worked somehow in the >> same country as that guard? Or perhaps were the other failed circuits >> all seemingly unrelated to the guard? >> >> As far as the ExcludeNodes - did you set StrictNodes at the same time? >> Are you also a relay? > >Any other configuration info would be helpful here too. Okay. Skipping over local port and IP address usage, here's some client-side stuff. TunnelDirConns 1 PreferTunneledDirConns 1 UseEntryGuards 1 NumEntryGuards [if you really need the number here, let me know--SB] AllowDotExit 0 LongLivedPorts 20-23,47,115,119,143,144,152,178,194,563,706,989,990,992-994,1863,5050,5190-5193,5222,5223,6000-6063,6523,6667,6697,8021,8300 There are also several NodeFamily statements and extensive ExcludeNodes and ExludeExitNodes statements. If there is other stuff you want, let me know, but depending upon what you ask for, I may choose to send it to you directly rather than post it here. > >(To answer your question: looking through the changelogs, and the >commit logs for src/or/circuitbuild.c and src/or/routerlist.c, I can't >find anything that stands out to me as something that might cause an >ExcludeNodes regression. So more investigation will be needed!) > The only thing remotely related that I saw was the following item in the Changelog for 0.2.3.15-rc. o Minor bugfixes (on 0.2.2.x and earlier): . . . - After we pick a directory mirror, we would refuse to use it if it's in our ExcludeExitNodes list, resulting in mysterious failures to bootstrap for people who just wanted to avoid exiting from certain locations. Fixes bug 5623; bugfix on 0.2.2.25-alpha. It probably has nothing to do with what has been causing me trouble, but it was the only item I found about either of the Exclude{,Exit}Nodes statement that mentioned a change between 0.2.3.13-alpha and 0.2.3.18-rc. Scott

1 0

Tor Weather - Node Down
by torhoste＠tor.host-ed.me 12 Sep '12

12 Sep '12

Hi, this is my very first post to this list. I operate tor exit relays vks24784 and vks24949 and subscribed to Tor Weather Reports. Now, at Sun, September 2, 2012 12:17 am and Thu, September 6, 2012 12:33 am, I received "Node Down" Reports for either of the nodes, 1st report for vks24949, 2nd for vks24784. That said, I noticed that these events reset the respective uptime counters at Atlas web application to "zero" and the nodes would lose the already earned stable, guard, named, etc. flags for a certain time period. The problem is that both nodes definitely were online to the best of my knowledge (they are 24/7 actually), please see the official Atlas logs at https://atlas.torproject.org/#details/AAD948023527A6D33FAA96816E4B5F101A664… and https://atlas.torproject.org/#details/B41CBB97CF4DCFF724F272F28FD3F0D683C2F… I even checked the "uptime" through ssh and there hasn't been any reboots occurring. Also, I'm wondering what actually would happen to guard, stable, named, etc. flags if I'd actually need to reboot the nodes cause of maintenance? I feel it unfortunate to lose these flags (also for the Tor network itself(?)) and would like to ask: 1. What does Tor Weather consider a "Node Down" event? 2. How long does it take to regain the mentioned flags? I.e. does the node start from scratch earning them (so to speak), i.e. does it take as long as initially? Last thing I'd like to ask in that context: Do these "Node Down" events and/or needed maintenance reboots have any effect on a potential Tor T-Shirt claim? I'd actually really like to make myself a communicative, green Tor advertising column at some point in time ;-) Thanks!

2 1

Re: [tor-relays] [OT] ExcludeNodes no longer working
by Scott Bennett 12 Sep '12

12 Sep '12

On Tue, 11 Sep 2012 16:12:36 -0400 Nick Mathewson <nickm(a)freehaven.net> wrote: >On Tue, Sep 11, 2012 at 1:52 PM, Steve Snyder <swsnyder(a)snydernet.net> wrote: >> On Tuesday, September 11, 2012 1:12pm, "Jacob Appelbaum" <jacob(a)appelbaum.net> said: >> [snip] >>> It seems that there are two issues - one is that a guard is failing to >>> build circuits, the other is that you can't seem to exclude them. I have >>> to admit, I'm more interested in the former... Is there a pattern to the >>> failures? >> >> I get those same messages occasionally. The following are from last week (v0.2.3.20-rc), seen from a Los Angeles datacenter. I haven't seen this rate of complaint before or since so I wrote it off as a fluke. >> >> Sep 01 05:20:31.000 [notice] Low circuit success rate 3/21 for guard BramaH4=39A0907D409836D7F014364C5FF5AC1DA79E0289. >> Sep 01 05:21:52.000 [notice] Low circuit success rate 6/21 for guard TORy2=F08F537D245A65D9C242359983718A19650A25F7. > >This looks like bug #6475. Those warnings should be suppressed in >0.2.3.31-rc and fixed for real in 0.2.4.x. ^^ Yikes. I do hope that was a typo. 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 * **********************************************************************

1 0

Re: [tor-relays] [OT] ExcludeNodes no longer working
by Scott Bennett 12 Sep '12

12 Sep '12

Hi Jacob et al., On Tue, 11 Sep 2012 17:12:06 +0000 Jacob Appelbaum <jacob(a)appelbaum.net> wrote: >It is nice to see you posting again, I had wondered where you had gone. I've been here all along, but didn't have anything to say until this matter came up. > >Scott Bennett: >> I know this really belongs on tor-talk, but I haven't been subscribed >> to it for a long time now. Sorry if posting this here bothers anyone. > > >Seems like a fine place to discuss relay problems, which is what it >sounds like, no? Um, no, it seems to me that Exclude{,Exit}Node matters are client-side stuff. That's where the circuit routes are selected, which is where those torrc lines come into play, right? > >> Back in early July, I upgraded from 0.2.3.13-alpha to 0.2.3.18-rc. >> I immediately ran into problems with a python script that honors the >> http_proxy environment variable, which I normally have set to the localhost >> port for privoxy, which, in turn, connects to tor's SOCKS port. I couldn't >> really see what was going wrong, but using arm to ask for a new identity >> seemed to help sometimes to get a circuit that worked. Sending tor a >> SIGHUP instead also seemed to work about as often. > >If you use 0.2.2.x - what happens? No idea. I haven't built a "stable" version in at least five years, probably longer. > >> A bit over a week ago, I switched to 0.2.3.20-rc, and the problem >> still occurs. However, 0.2.3.20-rc now also emits a new message from time >> to time, the most recent occurrence of which is >> >> Sep 06 06:02:45.934 [notice] Low circuit success rate 7/21 for guard TORy0=753E0B5922E34BF98F0D21CC08EA7D1ADEEE2F6B. >> > >That is an interesting message - I wonder if the author of that message >might chime in? > >> Wondering whether such circuit-building failures might be related to the >> other problem, I began a little experiment: each time I saw a "Low circuit >> success rate" message, I added the key fingerprint of the node in question >> to my ExcludeNodes list in torrc and sent tor a SIGHUP. >> The problem is still occurring, though, and when I look at the >> circuits involved, they all seem to have at least one of the excluded >> nodes in them, usually in the entry position. So my question is, what >> changed between 0.2.3.13-alpha and 0.2.3.18-rc (or possibly 0.2.3.20-rc) >> in the handling of nodes listed in the ExcludeNodes line in torrc? And >> is there anything I can do to get the ExcludeNodes list to work again >> the way it used to work? >> Thanks in advance for any relevant information. >> > >It seems that there are two issues - one is that a guard is failing to >build circuits, the other is that you can't seem to exclude them. I have Right, but the guard's problem really shouldn't be my problem, although I suppose I could try emailing the node's operator about it. >to admit, I'm more interested in the former... Is there a pattern to the >failures? That is for the 7 successes for that node, did you see >anything interesting? Were say, the nodes that worked somehow in the >same country as that guard? Or perhaps were the other failed circuits >all seemingly unrelated to the guard? I haven't the foggiest. I don't even know over how much time tor has been calculating the ratio before it decides to issue that message. It could be minutes, hours, days... The failures I started getting with 0.2.3.18-rc were really irritating, but I didn't have a clue to follow until switching to 0.2.3.20-rc, which issues the interesting messages. That prompted me to turn INFO logging back on and watch what happened when I ran that script. Between the log and looking at arm's display of current circuit routes, I was able to see that nodes were being used that were supposed to have been excluded. > >As far as the ExcludeNodes - did you set StrictNodes at the same time? No. However, there are usually 800 - 900 guards active at any time these days, so I figured that excluding only the ones that gave me trouble would leave plenty of others available for selection. >Are you also a relay? Yes. See MYCROFTsOtherChild in the consensus, descriptors, or tor status pages. It's the same one I've been running for years, apart from short hiatuses in 2007 and 2008. Scott

1 0

Tor Weather - Node Down
by torhoste＠tor.host-ed.me 11 Sep '12

11 Sep '12

Hi, this is my very first post to this list. I operate tor exit relays vks24784 and vks24949 and subscribed to Tor Weather Reports. Now, at Sun, September 2, 2012 12:17 am and Thu, September 6, 2012 12:33 am, I received "Node Down" Reports for one of the nodes, 1st report for vks24949, 2nd for vks24784. That said, I noticed that these event resets the respective uptime counters at Atlas web application to "zero" and the node would lose the already earned stable, guard, named, etc. flags for a certain time period. The problem is that both nodes definitely were online to the best of my knowledge (they are 24/7 actually), see http://tor.host-ed.me/nodes/ and official Atlas logs at https://atlas.torproject.org/#details/AAD948023527A6D33FAA96816E4B5F101A664… and https://atlas.torproject.org/#details/B41CBB97CF4DCFF724F272F28FD3F0D683C2F… I even checked the "uptime" through ssh and there hasn't been any reboots occurring. Also, I'm wondering what actually would happen to guard, stable, named, etc. flags if I'd actually need to reboot the nodes cause of maintenance? I feel it unfortunate to lose these flags (also for the Tor network itself) and would like to ask: 1. What does Tor Weather consider a "Node Down" event? 2. How long does it take to regain the mentioned flags? I.e. does the node start from scratch earning them (so to speak), i.e. does it take as long as initially? Last thing I'd like to ask in that context: Do these "Node Down" events and/or needed maintenance reboots have any effect on a potential Tor T-Shirt claim? I'd actually really like to make myself a communicative, green Tor advertising column at some point in time ;-) Thanks!

1 0

GPG error
by Ottakar 10 Sep '12

10 Sep '12

Hi everyone, my node is actually down and when I want to update my debian, I' got a GPG error: root@foo:/home# apt-get update W: Une erreur s'est produite lors du contrôle de la signature. Le dépôt n'est pas mis à jour et les fichiers d'index précédents seront utilisés. Erreur de GPG : http://deb.torproject.org squeeze Release : Les signatures suivantes ne sont pas valables : KEYEXPIRED 1346668560 KEYEXPIRED 1346668560 KEYEXPIRED 1346668560 KEYEXPIRED 1346668560 W: Impossible de récupérer http://deb.torproject.org/torproject.org/dists/squeeze/Release W: Le téléchargement de quelques fichiers d'index a échoué, ils ont été ignorés, ou les anciens ont été utilisés à la place. Where can I find the procedure to update the GPG key? Thx

3 2

Subsidizezed relay proposal
by Dude 10 Sep '12

10 Sep '12

I want to share my thoughts and get feedback on operating a sponsored dedicated exit relay. 0. register a domain name 1. set up a centos linux based dedicated server at a Tor compatible ISP in the USA a. get myself set up as abuse contact for my IPs (I have worked the abuse alias before) b. "10MB" net connection. Most 100MB give you around 9 MB actual and 10 MB give you 6MB actual 2. set up a 'mostly public' exit node and run it intermittently while I tune and debug it 3. operate node for a month before submitting receipts for funding 4. add more nodes if this works I realized I have no assets, so I am going to hold off from creating a LLC type company for financial protection. Are there any more specifics and how/when subsidies will be released? Cheers!

1 0

Current state of v0.2.3.x IPv6 bridges?
by Steve Snyder 10 Sep '12

10 Sep '12

I'm wondering about the benefit of running abridge on an IPv6 address. Since the big announcement last December that v0.2.3.9 supports IPv6 addresses for bridges, I've read a few comments to the affect that BridgDB doesn't understand IPv6 addresses. So... what is the state of publishing IPv6 bridge addresses? Will clients requesting a bridge address ever be given an IPv6 address? Can a client specifically request an IPv6 address (or IPv4 address, for that matter)? Thanks.

3 2

Repository
by Jörg Frings-Fürst 06 Sep '12

06 Sep '12

Hi, I got the following error on every update. Pls fix it.. Jörg Frings-Fürst W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.torproject.org precise InRelease: The following signatures were invalid: KEYEXPIRED 1346668560 KEYEXPIRED 1346668560 KEYEXPIRED 1346668560 KEYEXPIRED 1346668560 > > W: Failed to fetch http://deb.torproject.org/torproject.org/dists/precise/InRelease > > W: Some index files failed to download. They have been ignored, or old ones used instead. >

2 1

Operating a sponsored relay II
by Dude 31 Aug '12

31 Aug '12

My research is telling me I can not host a Tor relay at most retail ISPs because it is perceived as an "open relay" and these cause a lot of headaches for ISPs. So that leaves colo, but this gets expensive fast. This is very expensive outside the USA. Could I work as an agent of torservers.net? Is there a FAQ listing friendly ISPs? I understand the need for documentation and receipts for expenses. It might be helpful to get quarterly payments instead of monthly. I was thinking of an USA Llc. for protection. Looking at my notes I now remember an 's-corp' is better for a single owner (simple corporation). Here is a link to the US commercial code for s-corps: http://www.gpo.gov/fdsys/pkg/USCODE-2011-title26/html/USCODE-2011-title26-s… I would be happy to document the process of setting up a US s-corp. if I create one. Cheers!

3 2

Has anyone had any success running a relay on an mk802?
by someonelse 30 Aug '12

30 Aug '12

I currently run a relay at home during the day, but would like to run one 24/7. Has anyone had any success doing this with the mk802 or similar device? This site seems to say it's possible: http://romanrm.ru/en/a10/mk802-server "It can run Web/Mail/DNS/DHCP/VPN/Jabber/Mumble/Tor servers..." I think this may work for me since I prefer Debian, something inexpensive (~$70 qualifies), low power and want to run wired Internet. If not the mk802 or mk802-II, then what device would do this better for around the same price? Thanks, Someonelse

1 0

Operating a sponsored relay
by Dude 29 Aug '12

29 Aug '12

Hello, I have experience working at ISPs supporting dedicated servers and am interested in operating a sponsored relay. Potential issues I see: # A true 100mb network connection is going to be expensive. Often a 24 port edge switch has just one 100mb uplink port. # As an operator, I might want an LLC to protect me from personal liability in the USA. # Ideally an ISP outside the USA would be used so the server is in a different legal jurisdiction than the operator. This would make payment and communication more difficult. At this time I imagine a server with an encrypted file system and long term log retention disabled. Reasonably hardened OS, but nothing too exotic. I think $100 a month above other costs would be fair. But I do not know how much attention a node would require once it was set up. If it requires a lot of time, more compensation would be in order. I am not looking to make a lot of money doing this, but I can not do it gratis. Cheers, John

2 1

Re: [tor-relays] "Relay info kit" for Tor exits at universities
by Scott Bennett 25 Aug '12

25 Aug '12

On Sat, 11 Aug 2012 04:08:57 -0400 Roger Dingledine <arma(a)mit.edu> wrote: >I've spent the week talking to my contacts at US universities, to get >them to spin up fast exits. Currently the fast exits in North American >universities are: > >- University of Waterloo (Ian Goldberg) >- Boston University (Leo Reyzin) > >We're now on track to add: >- UPenn (Matt Blaze) >- UMichigan (Alex Halderman) >- CMU (Nicolas Christin) >- Georgia Tech (Dave Dagon) > >and I have professors from George Mason, Illinois, UNM, UMN, UConn, >UW, and others looking into it. > >Wendy and I are talking to some lawyers to try to write up a short >(several paragraph) document targeted toward the university's general >counsel, for preemptive use by the computer science professors who plan >to run the Tor exit. > >What else should go in a "so you want to run a big exit" info kit? > >- Pointers to the legal-faq (and dmca template) and abuse-faq. > >- Pointers to Mike's blog entry: >https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment >and my old Tor-at-universities wiki page: >https://trac.torproject.org/projects/tor/wiki/doc/TorGuideUniversities > >- Is there some document suggesting how to SWIP your address, and >explaining the importance of having your abuse mails go to someplace >other than your general university abuse team? It's touched on in several >places but we should make it even clearer. > >- What are the good answers now to "what hardware should I use, and how >should I configure it?" I've been telling people they'll be happiest with >Debian, and that something 64-bit and/or with AESNI support will be best. Fast relays use lots of memory, which vastly worsens the effects of the "small TLB" problem inherent in all modern CPUs, so running a fast relay on a FreeBSD kernel with superpages support enabled is likely to reduce considerably the CPU load for the traffic served, which is more or less equivalent to increasing the traffic capacity for any given CPU speed. Superpages support has been available since 7.2 for i386 and amd64 platforms, but will likely be available on other platforms at some point. Support on another platform was supposed to appear in 9.0, IIRC, but I don't remember which (ia64?). I'm not sure what will be in later releases, but my understanding is that the kernel development team planned to add superpages support eventually to the rest of the FreeBSD-supported hardware platforms that are capable of it (not, for example, powerpc because that hardware does not support the multiple page sizes involved). Rather than risk triggering OS religious wars here, it might be better to limit OS recommendations to merely which to avoid because they have limitations likely to prevent successful operation of a fast exit node (e.g., non-server versions of Windows). The administrators of fast nodes already know what their current setups are and the current knowledge bases of their staffs are. > >- [remainder deleted -SB] 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 * **********************************************************************

1 0

"Relay info kit" for Tor exits at universities
by Roger Dingledine 24 Aug '12

24 Aug '12

I've spent the week talking to my contacts at US universities, to get them to spin up fast exits. Currently the fast exits in North American universities are: - University of Waterloo (Ian Goldberg) - Boston University (Leo Reyzin) We're now on track to add: - UPenn (Matt Blaze) - UMichigan (Alex Halderman) - CMU (Nicolas Christin) - Georgia Tech (Dave Dagon) and I have professors from George Mason, Illinois, UNM, UMN, UConn, UW, and others looking into it. Wendy and I are talking to some lawyers to try to write up a short (several paragraph) document targeted toward the university's general counsel, for preemptive use by the computer science professors who plan to run the Tor exit. What else should go in a "so you want to run a big exit" info kit? - Pointers to the legal-faq (and dmca template) and abuse-faq. - Pointers to Mike's blog entry: https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment and my old Tor-at-universities wiki page: https://trac.torproject.org/projects/tor/wiki/doc/TorGuideUniversities - Is there some document suggesting how to SWIP your address, and explaining the importance of having your abuse mails go to someplace other than your general university abuse team? It's touched on in several places but we should make it even clearer. - What are the good answers now to "what hardware should I use, and how should I configure it?" I've been telling people they'll be happiest with Debian, and that something 64-bit and/or with AESNI support will be best. - We should set up a mailing list for university relay operators to share experiences and feel solidarity. I'll also encourage them to sign up here. We might also post a list of university Tor exits somewhere obvious, so new ones can gain more confidence in the idea. What other resources exist already that would be especially useful for new fast exits? What resources don't exist but should? --Roger

7 14

exit node with different IP address
by cmeclax-sazri 22 Aug '12

22 Aug '12

I rebooted my computer with a freshly compiled kernel and world, brought up my browser, and before doing something where I need to know my IP address is hidden, brought up check.torproject.org. It said "You are not using Tor." But the address is 217.148.84.179, which isn't anywhere near me. So I brought up torstatus.blutmagie.de and searched the page. It lists AMORPHIS at 217.148.84.180. I don't see ExitAddress in torrc. Should there be one? cmeclax

2 1

hi
by P.H. H 19 Aug '12

19 Aug '12

tor-relays(a)lists.torproject.org

2 1

Notice of disruption of service
by Dennis Ljungmark 17 Aug '12

17 Aug '12

Hi all, I'm sad to say that I've been forced to disable three of our six relays, and reduce the others to minimal transfer speeds. We are currently being exhorted by our ISP, Bahnhof for a huge amount of money due to "excessive traffic" in order to sign us up on a new contract. This should serve as a warning call for people who are using or considering to use Bahnhof. Contact take(a)deklomp.se for more information about the case. The affected nodes are: ( Reduced speed ) depth 9EDB9965625A06F41D84581BF66CAF7D79919DC4 vandalise 8D3E65A90F455E77DEFAA9ACEAFD7392221E2C9C deklomp1 0A9CB1B43C780634B80390A9093C7490CB503880 ( Offline until the issues are resolved ) deklomp2 EFA394DD66A8147AAEF3604B37CBF77DE2C7D895 deklomp3 FB5BECE11DDCE8444CB2EB0A41303DBB7093EA7A deklomp4 2403121E35A830A7131C388EB643915F06842FB4 Regards, D.S. "Spider" Ljungmark

2 2

Help the Tor Project by running a fast unpublished bridge
by Roger Dingledine 16 Aug '12

16 Aug '12

Hi folks, In addition to the "get many fast exit relays" plan, that same funder (Voice of America) wants us to run a pile of fast stable unpublished bridges. We'll give the bridge addresses out manually to their target users over the coming months. The constraints are: * 100mbit+ connectivity, though in practice I expect they will spend most of their time doing far less than that. * No more than 2 bridges per /24. If you're running fast (100mbit+) exits (which is more important), exits on that /24 count toward this 2. * No more than 7 bridges total per data center. If you could set up 1 (or 2, or 20) and send me the address(es) privately, that would be grand. We do have some funding for this, but I'm hoping that we can get enough volunteers so we can put the money toward more fast exits and better QA and build automation for the Tor bundles. So if you have good connectivity but can't run an exit, this is a great way to contribute. The torrc lines we want include: ORPort 443 # or whichever port you like BridgeRelay 1 PublishServerDescriptor 0 RelayBandwidthRate 11875 KB # or more RelayBandwidthBurst 12500 KB # or more If you have 3+ IP addresses and want to get fancy, you might set OutboundBindAddress to a different IP address than you tell me, to avoid some of the bridge enumeration attacks listed at https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-br… Later I might ask you to set up some sort of server-side pluggable transport like obfsproxy, but there's no rush on that. Long-term, "get a bunch of fast bridges on individual static IP addresses" is not a very good plan. Instead, we plan to focus on borrowing whole netblocks from ISPs and other people who aren't using them, and redirecting the addresses en masse into a bridge. You can start playing around with this idea by using an iptables rule rather than a bridge: /sbin/iptables -t nat -A PREROUTING -p tcp -d 18.244.0.114 --dport 80 -j DNAT --to-destination 128.31.0.34:9032 if the bridge listens on 128.31.0.34:9032 and you want me to advertise the address 18.244.0.114:80. Let me know if you have any questions or I can help clarify anything. Thanks! --Roger

9 19

Exit Port Usage Statistics for "Allow all" nodes
by Moritz Bartl 16 Aug '12

16 Aug '12

Hi, At torservers.net, we run some large exit relays with an "allow all except port 25" policy. These are statistics from ARM showing exit port statistics of a fast exit running for seven hours at 30-40 MB/s: 443 HTTPS 17650 (%55) 80 HTTP 10625 (%33) 8344 739 (%2) 8333 84 51413 45 6881 Torrent 38 8337 29 993 IMAPS 23 45682 18 182 16 9001 16 4662 eMule 14 4661 12 -- Moritz Bartl https://www.torservers.net/

4 4

Using aes-in in Tor
by tor-admin 15 Aug '12

15 Aug '12

Hi, I am struggling setting up aes-in support with Ubuntu 12.04 LTS. I enabled aes in bios. cat /proc/cpuinfo shows the aes flag. #lsmod |grep aes aesni_intel 55664 0 cryptd 20530 1 aesni_intel aes_x86_64 17208 1 aesni_intel shows that the module is loaded. But #openssl engine (rsax) RSAX engine support (dynamic) Dynamic engine loading support shows not the aes engine. My openssl version is #openssl version OpenSSL 1.0.1 14 Mar 2012 Can someone give me a hint what I am doing wrong. Regards, Torland

3 4

Unnamed flag
by kupo＠damnfbi.tk 15 Aug '12

15 Aug '12

Can anyone explain how to get the Unnamed flag for my node changed over to Named? -kupo

4 3

Re: [tor-relays] Call for discussion: turning funding into more exit relays
by Martin Algö 15 Aug '12

15 Aug '12

Hi Roger, Thanks for your answer :) It's funny that you mention dfri.se, because they e-mailed me (and all swedish relay operators i believe) yesterday and I'm lurking in their IRC channel (and #tor) as I write this. I also managed to join the tor-relays list, so I've had a lot to read lately. I'm CC'ing this to them as well, so let's see if it gets to where it's supposed to. :) Cheers! //Martin 2012/8/14 Roger Dingledine <arma(a)mit.edu> > (Adding the tor-assistants cc back in -- I'm not so good at handling > mail to me directly, and tor-assistants is a closed list of other Tor > developers, so hopefully it isn't too impolite to add it.) > > On Tue, Jul 24, 2012 at 12:42:03PM +0200, Martin Algö wrote: > > Hello Roger, > > > > My answers first: > > > > - What do you currently pay for hosting/bandwidth, and how much bandwidth > > do you get for that? > > I'm running my relay from home. I have a 100Mbit connection and for that > i > > pay roughly $65 USD (450 SEK). > > > > - Is it a stable hosting situation? For example, how do they handle > > abuse complaints so far? > > So far I've been running my relay for about 18 months. The Tor server > uses > > a total of about 50Mbit constantly in both directions (I limited it > because > > I want some bandwidth for myself as well) and I have not heard a peep > from > > my ISP. It should be noted that my ISP (Bahnhof, Sweden) have been known > > for engaging in discussions about privacy in general and trying to > protect > > their users from things like ACTA/IPRED. They even supply their own > > anonymity VPN service. > > I tried contacting them once to talk about Tor, but whoever at helpdesk > > that got my email didn't know what I was talking about so I gave that up, > > thinking that I shouldnt rock the boat unless necessary. :) > > Great. I wish there were more people like you in Sweden. :) > > > - Is your hosting situation one where it could make sense for us to > > reimburse your bandwidth costs? (Some people have a deal through their > > employer, friend, etc where they don't pay for hosting.) > > Yes. In my case, I use half my bandwidth and so it would make sense to > pay > > me half my connection fee. Something that I would like much more though, > > would be a promise of economic assistance in case of juridical problems. > > The way i see it, I don't give any money to charity, such as Red Cross > etc. > > but I contribute bandwidth for a value of $30-35 every month to help > > anonymity and uncensored access to the internet for user that need it. > > (Along with users that use it for bad things as well, but that is a > > tradeoff I'm willing to make for now.) > > Good idea. Do you know about dfri.se? They are running some fast exit > relays in Sweden in an organized way. I bet they could help with the > legal side. I agree that it would be great to have some equivalent of the > Tor Legal FAQ written with Sweden in mind. I'm cc'ing Linus (from dfri) > in case he has any thoughts here. > > > relay if you didn't have to pay for it? > > This is an interesting question! Maybe I could buy a VPS somewhere? I'm > the > > local "IT guy" at my office so I might be able to buy a separate > connection > > there and even get some cheap hardware. This defenitely could require > some > > thinking on my part. > > Let us know if anything comes to mind, and what we can do to help. > > > - What else should we be asking here? :) > > What do the relay operators want? :) > > As stated above, for me it would mean much more to have some legal help > to > > fall back on if (when) shit hits the fan. I'm not sure, but I'm guessing > > that many would-be high speed relay operators don't run relays because of > > possible legal imlications. > > Right. Do you know good Swedish lawyers who might be able to help > clarify how the laws there work? > > > I would love to join the discussion on the tor-relays list. I already > > registered, but I never got around to using any mailing lists before, so > > I'm not sure how to respond to your thread without breaking anything. > Help > > a n00b will you? :) > > Happy to help. I'd say just send the mail and see what happens. If > you start with "I run a fast exit relay, and", I expect people will be > very friendly. > > Thanks! > --Roger > >

2 1

Sizing, Pricing, Effect
by Dennis Ljungmark 06 Aug '12

06 Aug '12

Hi! [Hypothetical part below] We have been involved with our ISP and there may ( discussions will have to wait until after summer vacation is over when we can find real numbers and answers) but it looks as if it'd cost us ~800€ / month to go from ~1GBit to 10GBit connection. If funding was available, this would be 9.5 GBit dedicated to Tor as Exit node + relays depending on what needs people have. [End hypothetical] Even without funding, we are still looking at transforming (some) of our existing relay nodes into Exit nodes, and there's a few practical questions here. Would you rather have several smaller ones, spread out via DHCP allocated ranges, or is it preferrable to have one or a handful of "larger" exit nodes? Regards, D.S. Ljungmark

1 0

tcmalloc in FreeBSD
by Jordi Espasa Clofent 06 Aug '12

06 Aug '12

Hi all, From time to time my tor node (minibofh) stopped to work properly; since it's a tiny FreeBSD VPS, the root origin was some CPU over-consumption. I'm taking some actions to fix it (more swap, freeing CPU from another services... etc). The FreeBSD tor port offers to you the tcmalloc compilation option, so I had some fun reading this interesting paper: http://goog-perftools.sourceforge.net/doc/tcmalloc.html I recompiled the tor port but just using the tcmalloc option. Actually, now I got the google-perftool package and, obviously, the tcmalloc library: mb# pkg_info | grep google google-perftools-1.8.3 Fast, multi-threaded malloc() and nifty performance analysi mb# pkg_info -L google-perftools-1.8.3 | grep malloc.so /usr/local/lib/libtcmalloc.so /usr/local/lib/libtcmalloc.so.2 But, when I'm checking which libraries the tor binary is using, I get: mb# ldd /usr/local/bin/tor /usr/local/bin/tor: libz.so.5 => /lib/libz.so.5 (0x281aa000) libm.so.5 => /lib/libm.so.5 (0x281bc000) libevent-2.0.so.6 => /usr/local/lib/event2/libevent-2.0.so.6 (0x2844e000) libssl.so.7 => /usr/local/lib/libssl.so.7 (0x28489000) libcrypto.so.7 => /usr/local/lib/libcrypto.so.7 (0x284d7000) libthr.so.3 => /lib/libthr.so.3 (0x281df000) libc.so.7 => /lib/libc.so.7 (0x28090000) So... I understand that the tor binary is actually NOT using the new tcmalloc library. Am I wrong? PS. I adding a CC to tor FreeBSD port mantainer.

2 2

Re: [tor-relays] [tor-assistants] Call for discussion: turning funding into more exit relays
by Andrew Beveridge 05 Aug '12

05 Aug '12

---------- Forwarded message ---------- From: TechFix LTD <andrew(a)techfixuk.com> Date: Wed, Aug 1, 2012 at 8:25 AM Subject: Re: [tor-assistants] Call for discussion: turning funding into more exit relays To: Roger Dingledine <arma(a)mit.edu> Cc: tor-relays(a)lists.torproject.org On Wed, Aug 1, 2012 at 5:03 AM, Roger Dingledine <arma(a)mit.edu> wrote: > Sounds like you should bump it up to 100mbit then. ;) > Heh, I've just done exactly that - well, I've raised the bandwidth limits in my torrc to values higher than what my ISP caps my connection at. Just to clarify though, is there any technical reason why it would be better practice to have a realistic configured limit (like 12.5MB) as the limit rather than something higher than that which I know will likely never actually be possible? I simply want to use all the bandwidth available. I'll monitor the websites I'm hosting from this server closely for a while and see if they are noticeably affected by this at all. They are hosted from a separate VM and I'm not sure how the OpenVZ host schedules packets going through the virtual network adapters, but I'm hoping that tor can run at maximum capacity most of the time while only adding perhaps a second or two of load time onto the websites. > You can see on http://atlas.torproject.org/#details/FA02311AF49EB663CA2685A8604C403A9E10E6… that there are periods where your rate limiting is bottlenecking traffic. I presume you're referring to the busy periods where the graph clips? Sure, but as my company pays for the server entirely, if it were to not function for its intended purpose (basic hosting of small-time client websites) I would have a problem. I was worried that allowing tor to use all my bandwidth would cause that, but I hadn't actually experimented with it to see - I'm doing that now! > > I definitely don't want Tor to be in the middle of the transactions -- if Tor pays the bills directly, that's too much like being the relay operator. One nice situation would be for you to produce receipts showing expenses, and then we reimburse those costs. It requires fronting a bit of money on your part, but that's part of saving the world, yes? :) > Ultimately, we're also going to want to look into reducing overhead on Tor's side from sending out money. If we have to write and mail 50 checks every month, that's going to waste a lot of somebody's time. Maybe that means Paypal is the way to go. Maybe it means we send some money in bulk to Zwiebelfreunde, and they do intra-Europe wire transfers to the other Europeans (though I admit maybe that just shifts the time-wasting). Lots of options there. What would be best for you? Good point. I guess the solution which seems logical to me would be a standing order from Tor into my company account for the amount mentioned above, with my OVH invoice emailed to you as justification. As the amount would not change from month to month, a standing order could be set up once and never require any more attention unless I got cut off by OVH. Presumably that would require a european bank account under Tor's control - I'm not sure about how your connection with the Wau Holland Foundation works, but are they perhaps able to help with european transfers? If that is too awkward, then sure, PayPal (or one of several other e-Payment systems) is a fairly easy way to go about it, with the loss of a few % of the payment amount. My business currently uses PayPal for all payments from US entities, simply because it is easy. > All of this said, don't go out and start spending money quite yet. We should figure out these logistics first. And Tor should get a bit more of a handle on what this diversity thing should mean. And I should get buy-in from other Tor people for my plans here. :) > --Roger > I'm going to try my best to run my current node as a full 100Mbit node from now on anyway, even if that means paying for more traffic. As soon as things are ready at your end, I'm ready to start a second identical exit as described in my previous mail. I'm going to try and start looking for other providers, but I don't want to reinvent the wheel - is https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs kept up to date by many people here? Perhaps we could develop a slightly better system for tracking good/bad ISP experiences than a flat wiki page with countries? So my node has been running without any bandwidth restriction for a few days now, and I'm not noticing any critical speed problems from the websites I host. The latency drops significantly when the node is pushing traffic at max bandwidth, but that doesn't seem to be very often ( https://atlas.torproject.org/#details/FA02311AF49EB663CA2685A8604C403A9E10E… ). So, as it stands right now, I'm happy to run that node for free as I already have been. If the OVH manager decides I am very close to my initial 10TB traffic cap, I will have to limit the node again unless I can get some funding (£9-£18) for another 20TB each month. Out of curiosity, can anyone explain to me why my bandwidth /hasn't/ been maxed out the past few days? (at least, according to Atlas) -- * Andrew Beveridge, **Tor lurker / sympathizer / advocate, exit node maintainer.* Director / Computer Repair Technician @ TechFix LTD [ http://www.techfixuk.com] Freelance Web Developer @ [http://www.andrewbeveridge.co.uk] Tel/Fax: +44 (0) 1383269735 | * Email: tor(a)techfixuk.com <andrew(a)techfixuk.com> * * 5 Drum Road, Kelty, KY4 0DQ, Scotland *

1 0

Re: [tor-relays] task-6329 / tor relays stats patch
by Karsten Loesing 03 Aug '12

03 Aug '12

Hi Michael, I'm cc'ing tor-relays for the discussion here, because I figured if you're okay with sharing the patch, you're probably also okay with a public discussion of it. :) On 7/21/12 4:19 PM, Michael Zeltner wrote: > Hi Karsten, > > On my way out, and I would otherwise forget but here you go, maybe you'd like > this. > > Best from Metalab/Vienna, > Michael Thanks for sending the patch! Most of it looks good, but I took out the --family-for-fp option which, I think, isn't entirely correct. This option looks for relays having the given fingerprint in their family line, but it doesn't cross-check if the given relay has those relays in its family line, too. The option also doesn't look at nicknames (of relays with the Named flag) in family lines, which means it might miss some family members. Oh, and it would be really cool to have a -F or --by-family option to aggregate by families. I wonder if we should do the whole family-calculating business inside Onionoo and add a family_number field which has the same number for relays in the same family. The script could then look up the family number of the given relay and display all relays with that family number. Would that make sense? Want to extend the script once Onionoo has such a field? Thanks! Karsten

2 4

Re: [tor-relays] Call for discussion: turning funding into more exit relays
by Andrew Beveridge 03 Aug '12

03 Aug '12

On Mon, Jul 23, 2012 at 9:22 PM, Roger Dingledine <arma(a)mit.edu> wrote: > Hello Andrew, > > I wanted to draw your attention to a thread I've started on the tor-relays > list: > https://lists.torproject.org/pipermail/tor-relays/2012-July/001433.html > > Hi Roger, I'm not too familiar with mailing lists, so hopefully I'm not top posting or replying in the wrong place here. I'm simply replying to your email in Gmail with a CC to the tor-relays list. Sorry for the late reply, I've been away with no internet access for the past week. > In short, we have a funder who wants to sponsor more and faster Tor > exits, and we're brainstorming about how to use the money in a way that > makes the network stronger but also doesn't screw up the "community" > side of the Tor relay operator community. The first step is collecting > facts about the current fast Tor exit relays. > > Great! I've not been vocal in the Tor community before now, but I'd like to start, and I'm certainly happy to share my experience / thoughts. > - What do you currently pay for hosting/bandwidth, and how much bandwidth > do you get for that? > This is a complicated question, because I run a single Tor exit in a VPS on my company dedicated server. I run a local company doing computer repair and web development, and lease a single dedicated server from OVH (more specifically, Kimsufi) for a total of £64 a month (inc. VAT). That gets me the Kimsufi 16G dedicated server, a RIPE block of 4 extra IPs, and an external 2TB HDD. 100Mbit pipe, 10TB/month bandwidth. £0.87/TB if I go over that, so if I were to max out the bandwidth for an entire month, using around 30TB traffic, I would have to pay about £18 on top for the extra bandwidth. However, according to the OVH manager I never seem to go anywhere near the traffic limit, despite having had the exit set to use 50Mbit/s constantly for the past 3 months. As far as I'm concerned, it costs me nothing to run this exit node - my company needs the dedicated server regardless, and none of the ~50 websites I host use enough traffic to be affected by the fact that my server is using half it's available bandwidth for Tor. In an ideal world, I would rent a second Kimsufi server just for Tor purposes, which would cost £36/month (Kimsufi 16G) + £4/month (RIPE block). Therefore, if I were to participate in this experiment, I would say *£40 GBP / month* would get *10TB of 100 Mbit/s* exit traffic. Additional *20TB* traffic could be purchased for *£18 / month*, which would bring the maximum cost to *$92 USD / month.* > - Is it a stable hosting situation? For example, how do they handle > abuse complaints so far? > This is an important one, because OVH are not Tor-friendly. In fact, they aren't very friendly in general! Several people told me it was very foolish to run an exit node on an OVH server, since as soon as OVH get even a whiff of a complaint, they are quick to suspend. All my company-hosted websites are hosted on a second redundant server with another ISP so I'm not worried if OVH do find out and take that route and cut me off. I'm also not worried about legal issues, as I have positioned myself as a web-hosting customer of my own PLC, with terms and conditions absolving my PLC of any legal risks. In the off chance some legal authority were to come to my flat in britain, they would find no electrical equipment to seize as I own only a single laptop and it usually lives in my car or partners house anyway! As I have only been running this exit for 3 months, I am far from an authoritative voice on the issue of abuse complaints, but the most important thing is definitely SWIP as far as I can see it - the IP address I use for the exit is one from the RIPE block I lease and as such the abuse email is my own. I've had about 20 abuse report emails so far, all automated (by the looks of things) from some system within the brazilian government, following an Sqlmap SQL injection scan/attack on a few government sites. I replied to the first one with the standard template, got no reply, haven't worried about it since. I reckon if OVH found out I was running an exit they would be likely to cut me off fairly swiftly, but they don't seem to pay much attention to Kimsufi customers since it is their budget range with very slow (week+ per ticket) support and presumably low margins. I think that and me as the primary abuse contact for the IP mean it's likely to stay up for a while. If I do get any hassle, I'll defend it as far as I can from a business perspective, but if they don't give in I'll likely just cancel it and open a new Kimsufi lease - I very much doubt anyone is checking new invoices for similar details to past customers. > - Is your hosting situation one where it could make sense for us to > reimburse your bandwidth costs? (Some people have a deal through their > employer, friend, etc where they don't pay for hosting.) > I don't think so - as explained above, at present I don't pay a penny, but I can only offer about half of my available bandwidth as the server is used for many purposes. If I were to participate in this experiment, it would probably mean purchasing another Kimsufi just for this, and the cost of the server itself would be what I would be looking for financial help with. > - Are you in a position to get more bandwidth if you pay more? At what > rates? We're most interested in sponsoring >=100mbit relays. > Unfortunately the Kimsufi servers are capped at 100Mbit regardless of whether you want to pay more. OVH obviously have Gbit and 10Gbit servers available, but they are too expensive for this. There are obviously far better alternatives for higher bandwidth servers - a quick look tells me I could get a 1Gbit dedicated server with 100TB traffic from Leaseweb for €99 ($121) / month, so obviously if the money is there, more bandwidth and traffic can be had. I guess it boils down to how many people you can get interested in this - if plenty, lots of 100Mbit servers is presumably better than a few 10Gbit ones for the money as it aids network diversity, even if (worst case) they are all hosted by the same provider. > - Do you have other locations in mind where you would run another exit > relay if you didn't have to pay for it? > Definitely! As far as I'm concerned, I am not worried about legal issues as long as I can purchase hosting through my business and SWIP the IP, and I have plenty of free time to spend configuring servers and responding to abuse emails, so if I had the money I would happily be running exit nodes in any country I could find a hosting provider in - money is the hurdle for me. > - What else should we be asking here? :) > One thing which I haven't seen discussed yet is how funding would actually be connected with operators - I'm not sure if you were thinking about the funder(s) directly sending money to operators, or if The Tor Project Inc would be acting as a middleman? What money transfer mechanisms would be safe to use, how would you verify that the money was going to the right person, would The Tor Project Inc receive invoices directly from hosting companies or would operators email copies of invoices to someone and then some money would turn up in their bank accounts? What about PayPal, etc? Just a few thoughts :) Thanks! > --Roger Thanks for inviting me to share my thoughts on this! -Andrew

8 10

Domain name based policies (was: Call for discussion: turning funding into more exit relays)
by Nicolas Braud-Santoni 01 Aug '12

01 Aug '12

2012/8/1 Roger Dingledine <arma(a)mit.edu>: > On Tue, Jul 31, 2012 at 11:21:01AM +0100, mick wrote: >> Question for tor developers. How hard would it be to change the logic >> (and syntax) of exit policy in tor to allow domain based formulations >> like: >> >> reject *.gmail.com >> reject *aol.com > > Very hard. > > https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#Exitpoliciesshould… Hi, While I see how allowing wildcards and domains in policies would be more than challenging, wouldn't it be possible to : - resolve domain-names at Tor startup, and get all associated A and AAAA records - Repeat when record's TTL is reached. Of course, it wouldn't work for sites that don't advertise all their IPs. It would also require the Exit node's operator to run some DNS resolver (or trust an external one), but locally running unbound (for example) is quite simple. Moreover, the risk evoked in the FAQ is already present : if I poison an exit node's DNS resolver, wouldn't I be able to replace nytimes.com A record with some bogon, like 0.0.0.0 ? Nicolas

2 1

Re: [tor-relays] Call for discussion: turning funding into more exit relays
by Scott Bennett 01 Aug '12

01 Aug '12

On Fri, 27 Jul 2012 01:23:57 -0400 grarpamp <grarpamp(a)gmail.com> wrote: >>> 4) What exactly do we mean by diversity? >> >> I would look at this almost entirely from a jurisdictional and ISP level. I >> believe the biggest "sudden impact" threats to the tor network are going to >> be from legal changes (jurisdictional, i.e. "save the children, nullroute >> the nodes") and local business policy changes ("sorry tor customers, no more >> tor egress from our DC due to complaints"). > >I'm not sure which thread I mentioned this on so I'll put it here to be sure. >I think one main thing needed is a project to catalog all the current >exits as to their diversity... >Box: ISP/hoster, AS, datacenter, country, upstream AS/Tier-n path, >relay-operator >Relay-operator: country > >Without that, seems like placing nodes amounts to, 'Well, >we don't have any in Iran, let's go there'. If it turns out that >IP is more or less fed as a courtesy from UAE across the >gulf, there's not much gain. Repeat analysis for any of the >above parameters. > >More nodes are probably good, just not all as USA, Equinix, >Level3, with whatever hoster has a rack in all the DC's. I agree completely. But I would also like to add that, aside from Brasil, most of South America is still dark. Central America is not much better either. Many of those states are not especially cooperative with each other, politically speaking, yet they all need the benefits of commerce associated with the Internet. That combination strikes me as beneficial to placement of tor relays in as many of those countries as possible. Much of Africa may be worth closer examination for the same reasons. We really need to keep political diversity in view, especially given the large fractions of the tor network currently concentrated inside a mere handful of politically allied states. The Dictator of the U.S., for example, has already made the threat of shutting down the entire U.S. portion of the Internet, including relaying between other countries, which would certainly have a severely disruptive effect upon tor users all around the globe were it to happen under today's distribution of tor relays. Even more drastic would be if any of, for example, the U.K., France, Germany, or the Netherlands were to follow suit. Having countries like Venezuela, Bolivia, Peru, and Ecuador more tor-populated looks to me like a good thing. Another point I'd like to make is that I don't see why having one 100 MB/s relay is somehow better than having ten 10 MB/s relays or 20 5 MB/s relays. The superhigh-speed relays push operating system limits on the number of connections. Due to tor's design, distributing the workload of such relays across multiple CPU cores is problematic. Olaf Selke got around that problem by running four nodes on a quad-core machine with two IP addresses, but that meant that each node usually ran at less than 15 MB/s. For a superfast setup today, it might mean running multiple 25 MB/s nodes in similar fashion to what Olaf did, rather than a single 100 MB/s node. The benefit to tor users would seem to me to be the same either way, but the multinode method would not satisfy the demand of the funding source, as I understood it. Either way, though, the operating system limits may place keep a lid on the actual tor capacity of a very fast setup. From an infrastructure standpoint, I acknowledge that there can be problems in setting up really fast relays in Latin American countries. However, adding a few relays on the order of 500 - 5,000 KB/s in each Latin American country could probably be done, even if it meant they could only be set up in national capitals, which are mostly megalopolises of several million people, and might involve making special arrangements with the ISPs. Other major cities in some countries may also have the infrastructure to make moderately fast relays possible. 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 * **********************************************************************

1 0

How to protect yourself from network scanning
by amki 01 Aug '12

01 Aug '12

Hiho, I am hosting a 3-5MB/s tor exit relay but as of today my hoster has closed my server because of network scanning. Is there a known proper way to protect yourself from being used as a network scan relay? I've thought about constructing iptables rules to limit the number of SYN packets for the same host per second or such, but I'm not sure if this is allowed or will get me flagged as a bad exit node. My hoster is quite ok with us generating some abuse complaints per month, but does not want to route network scanning traffic since it is a severe load to their routers. Any help would be appreciated Cheers amki -- "Whatever the reason you're on Mars, I'm glad you're there, and I wish I was with you." - Carl Sagan

5 5

Re: [tor-relays] Call for discussion: turning funding into more exit relays
by Steve Snyder 01 Aug '12

01 Aug '12

Roger Dingledine arma at mit.edu Mon Jul 23 18:58:54 UTC 2012 [snip] >At the same time, much of our performance improvement comes from better >load balancing -- that is, concentrating traffic on the relays that can >handle it better. The result though is a direct tradeoff with relay >diversity: on today's network, clients choose one of the fastest 5 exit >relays around 25-30% of the time, and 80% of their choices come from a >pool of 40-50 relays. [snip] From what I see on the TorStatus pages (torstatus.all.de, blutmagie.de) about a third of the roughly 3000 relays listed are at or below 64KB/sec of demonstrated bandwidth. No doubt some of these are soon-to-be-high-bandwidth servers that are just ramping up, and some are nodes having transitory networking problems. It seems reasonable to assume, though, that most of these low-bandwidth nodes are intentionally low-bandwidth, perhaps on the basis of the Tor doc stating a 20KB/sec minimum. With "80% of their choices come from a pool of 40-50 relays" that leaves a 20% chance for the remaining 2950 nodes. A case for low-bandwidth nodes can be made as a means to dissuade anticipated routing (due to pool size), but it seems from the stats quoted above that there is little chance that 2000+ of these 3000 nodes will ever carry Tor traffic, and thus can be ignored for purposes of traffic analysis. Is there any justification for a low-bandwidth Tor node? And if so, what is the practical minimum bandwidth needed to actually see any traffic?

4 3

Re: [tor-relays] Call for discussion: turning funding into more exit relays
by Roger Dingledine 01 Aug '12

01 Aug '12

On Fri, Jul 27, 2012 at 05:49:34AM -0400, Motoko Kusanagi wrote: > I am very interested in running 100 Mbit (maybe even more) exit nodes at 100$/month, however, a question immediately comes to mind: > When we say "100Mbit exit node", do we imply "really unmetered" traffic at 100 Mbit, or do we mean "semi-reasonable traffic limit at 100Mbit speed". > "Really unlimited", in my experience, oftentimes turns out to be somewhat problematic. I don't think we necessarily need to have the 100mbit all to ourselves (see the other discussions here about shared connections), but I think it needs to be able to push a good fraction of 100mbit throughout the month. So something that can handle 20-30TB/mo is in the right ballpark. Note that many of our current 100mbit nodes are actually gbit nodes that try to limit themselves to a long-term average (95th percentile) of 100mbit. > I could arrange for 50-100 100Mbit exit nodes running 24/7, with a >traffic limit somewhere between 1 and 4 terabytes (will need to scrutinize >my current contract and do some math). Arranging for such a number of >"honestly unlimited traffic at 100Mbit speed" would be...significantly >more problematic. 4TB/mo is good for a 10mbit connection, but not good for a 100mbit connection. You'll end up either needing to hibernate for 80% of the month, or rate limit your relays down a lot. That said, we don't need 50-100 100mbit exit relays from any single group. Just 5-10 would be nice. Maybe that makes the capacity issue easier? --Roger

1 0

Re: [tor-relays] Negative impact of MaxOnionsPending 250?
by Scott Bennett 31 Jul '12

31 Jul '12

On Thu, 26 Jul 2012 17:11:17 +0200 Moritz Bartl <moritz(a)torservers.net> wrote: >We sometimes see "Your computer is too slow to handle this many circuit >creation requests!" on our servers. Scott Bennett suggested to set >MaxOnionsPending to 250 instead of the default of 100, which at least >makes the warnings disappear. [1] > >I am thinking about modifying out torrc template we use as as basis for >all servers. What is the negative impact of setting MaxOnionsPending to >250? Should we instead reduce the bandwidth as suggested in the warning? I don't think so. To the best of my recollection, I've only seen this message in recent versions of tor when it appeared that my node had been chosen for one or more high-volume hidden service operations, where the traffic volume in B/s was still fairly low, yet the number of connections had suddenly climbed to an unusually high level. The data throughput capacity vastly exceeded the actual traffic, but the onionskin-decoding load was sometimes, but probably not continually, very high until the hidden service(s) either shut down or changed their advertised information in the hidden service directory. To lower my node's RelayBandwidth* values would most likely have little impact on the bottleneck. Raising MaxOnionsPending adds a little slack in the queue to handle the occasions where that activity is temporarily backlogged prevents dropped connections and allows operations to proceed normally with only minimal extra delays. Consider a delay of probably no more than a second at the outside and usually less versus the delay of building a new circuit to a hidden service due to a dropped connection. > >[1] https://lists.torproject.org/pipermail/tor-relays/2012-May/001352.html 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 * **********************************************************************

1 0

Re: [tor-relays] Call for discussion: turning funding into more exit relays
by Zac Lym 30 Jul '12

30 Jul '12

This seems (to me) like an obvious suggestion, so my apologies if it's already been thought up. Why not establish a team/scoreboard system, like those used for distributed computing and BitCoin mining? This elegantly solves a few problems while with minimal resource commitment from the Tor organization. Most importantly, it's a way to pump money into the system without ruining the current atmosphere. Sponsors could easily buy some bandwidth or people can also just donate their own connections and join a particular team. The scoreboard is based on goodwill, not dollars spent. It also eliminates the hassle of setting prices, as teams can compete for dollars and bandwidth provided, essentially setting their own prices. The org could also setup a payment system, like we-pay, that the team admins can configure to deposit funds. It could be set as a proof of work system, paying after the bandwidth has been provided. This also allows a degree of control to prevent abuse from admins trying to juice stats by abusing some network infrastructure, like dummy trial accounts on hosting sites. A group admin could block specific hosts or the Tor project could remove an entire group. Finally, this could allow for the Tor project to create metrics based on things other than speed, akin to how Folding@home scores GPU and CPU contributions differently. Then the project can set anonymity goals for the network (such as location, ISP, backbone provider, etc) and the volunteers will adjust their patterns accordingly. Finally, I would like to strongly suggest taking a cut of all donations to pay for the new infrastructure and Tor research and development. I wouldn't want development to slow on Tor because donations are going to bandwidth instead. Indeed, I would prefer we spend a ton of money on the stenography efforts and usability. Anyway, thanks for the hard work! -Zach Lym

2 1

nickname to fingerprint
by Aichetou Med 28 Jul '12

28 Jul '12

hello tor community my question is : is there an "easy" way to translate relay nickname to fingerprint ? if not is it possible to download descriptors for some specific relays given "Digest" string from consensus file? i mean before launching tor. besides is there a reason for not showing the fingerprint in the consensus. thank you :)

2 1

Script to get top relays, AS and countries weights
by delber 27 Jul '12

27 Jul '12

Hi! Attached is a pretty simple Python script to compute some statistics about relays. Here's the doc: Usage: tor-relays-stats.py <output> [args ...] Where <output> is one of: - countries [FLAGS] relative percentage of the consensus in each countries - as-sets [FLAGS] [COUNTRIES] relative percentage of the consensus in each AS sets - top [COUNT] [FLAGS] [COUNTRIES] top relays according their place in the whole consensus Examples: - To get the top five exit nodes in France: tor-relays-stats.py top 5 Exit fr - To get weights of each AS of all relays in Germany: tor-relays-stats.py as-sets Running de Maybe it has flaws. Maybe it should land in some Git repository. I just felt it might be of interest to other folks. Feel free to comment and hack. -- delber

3 14

Negative impact of MaxOnionsPending 250?
by Moritz Bartl 26 Jul '12

26 Jul '12

Hi, We sometimes see "Your computer is too slow to handle this many circuit creation requests!" on our servers. Scott Bennett suggested to set MaxOnionsPending to 250 instead of the default of 100, which at least makes the warnings disappear. [1] I am thinking about modifying out torrc template we use as as basis for all servers. What is the negative impact of setting MaxOnionsPending to 250? Should we instead reduce the bandwidth as suggested in the warning? [1] https://lists.torproject.org/pipermail/tor-relays/2012-May/001352.html -- Moritz Bartl https://www.torservers.net/

2 1

High speed Relays/Exit nodes
by Dennis Ljungmark 26 Jul '12

26 Jul '12

Hi, We're currently running 6 different 100-200Mbit relay/guard nodes, and are looking at some issues moving on towards high performant exit nodes. There are some administrative issues ( needing another IP block due to the RIPE registration, our ISP doesn't want their name on the exit nodes that we are responsible for ) which are generally minor ( are being resolved anyhow ) and then the big stumbling block. Right now, with iptables modifications ( raw tables hacks to disable conntrack, bucket increases, following the general best practices ) our firewall is running at high amounts of CPU, but coping. However, once we start introducing Exit Nodes into this equation, things turn sour. So, since we do not want to trust only routing level separation between Exit Nodes and internal networks, we're going to have to invest into new hardware that can cope with this. Before this, we tried Ingate firewalls, and they weren't capable of coping with the load of guard nodes. ( The traditional "linux box in front" doesn't quite cut it due to networking hardware in most cases. ) So, in summary, when you get to the point of actively dealing with 8-900Mbps of Tor traffic ( on top of normal users and others) what hardware is needed to cope with firewalling? Regards, D.S. Ljungmark

3 3

Call for discussion: turning funding into more exit relays
by Sriakhil Gogineni 26 Jul '12

26 Jul '12

Hello! I saw this posted on slashdot and think this is an excellent way to donate some of our time and expertise, especially considering Internet access has been declared a human right by the UN. We currently colocate with a provider and will be inquiring with them if they are OK with hosting Tor, (the post here: https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment was extremely helpful for other just joining and we will be following such advice when we bring it up with our provider). Ball park quotes we got were 99$ / 100 Mbps or $599 / 1000 Mbps for transit for a single 1U... we'll see if we can get something better... Would this be helpful / viable option for a Tor exit node ? I also had just one question: what are the specs required for a Tor node? It does not seem too resource intensive but I have not been able to find any minimum system requirements. Would a current / last-generation quad core with 8GB + would suffice? Best, Sri

3 2

Paid exit nodes
by Brock Tice 25 Jul '12

25 Jul '12

Hi, I saw the story on Slashdot. I currently run an exit node (anfanillc) with a bandwidth limit. I have a decent uplink, though in bandwidth tests I see closer to 40 Mbps than 100 Mbps. I think $100/month would be plenty to defray the costs of removing the bandwidth limit. Maybe even less, I can talk with my ISP. I'm not charged for bandwidth right now, but my DC has to pay the ISP for it. I've already got my IP SWIPed and all that good stuff. Prior to this I've run exit nodes on and off for years without too much trouble, mostly DMCA takedowns. --Brock

1 0

How many PK operations does a typical home-run relay or bridge do in 24 hours?
by Karsten Loesing 18 Jul '12

18 Jul '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi relay and bridge operators, want to help us design hardware capabilities of a Torouter device? At the Florence hackfest I was asked for the typical number of RSA operations performed by a relay or bridge, say, per day. We're mostly interested in home-run relays and bridges on DSL lines and similar, because that's where Torouter devices will be deployed, too. So, Amunet and TorServers are out here. :) Tor has a built-in feature to count PK operations. If one sends a USR1 signal to the tor process, it writes a line like this to its log file (though this line comes from a client): Jul 10 18:31:22.904 [info] PK operations: 0 directory objects signed, 0 directory objects verified, 0 routerdescs signed, 2968 routerdescs verified, 216 onionskins encrypted, 0 onionskins decrypted, 30 client-side TLS handshakes, 0 server-side TLS handshakes, 0 rendezvous client operations, 0 rendezvous middle operations, 0 rendezvous server operations. The number we're most interested in is "onionskins decrypted," but maybe there are other high numbers that are worth considering. If you run a relay or bridge at home, run these four steps: 1. Make sure the relay or bridge is running for at least 24 hours (longer is fine, shorter may skew results) 2. Send the process a USR1 signal, e.g., kill -USR1 $pid 3. Look for the log line above 4. Reply to this email with a) the relay's or bridge's nickname, b) the first four hex characters of its fingerprint, c) the log time and timezone, d) the top-3 PK operations by numbers. An example result could be: gabelmoo F204 Jul 10 18:31:22.904 CEST 12345 onionskins decrypted 2968 routerdescs verified 216 onionskins encrypted Thanks for your help! Once I have some results, I'll look up relays and bridges in the descriptor archive and post results to this list. Of course, if someone has more thoughts on measuring how many PK ops a relay or bridge does, please say so! :) Thanks, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQAAjVAAoJEEk5d4GsWvIjWbMH/ilEf4dQrWqdFuZ5lYlWBnSb PAd/ru2ygGFswW4CeWWNKNnkxVd+Dcd9smVjVcpUIxlrEeMXzrZqsICre992Cjsd RjyXBnKIdwInwdVOi5ZyuWbmozCTbn5Oh3Bd47XFMDLNZIgC9itCdlGkU9Mw6bKB KO7QfbtQCTjlBEe/4mYmpW4/H+NaG5V8b3ByWtuAJz614cxckPgR2UxnEtYQXm7p TCRh/FC2jnc+7MrQZxBd6V6zLrudtdLCNLwdchGt7YBPMV3tyryvV6q/8v9ZY5jP VQTW6pKb5kVH1drL4M7oCJtt7bDnxhOGg76C7uBjWiXoaYUp4zyfeTdc57FkreM= =4Ex+ -----END PGP SIGNATURE-----

10 11

Re: [tor-relays] SocksPort flags trouble
by Scott Bennett 17 Jul '12

17 Jul '12

On Tue, 17 Jul 2012 09:34:08 -0400 Nick Mathewson <nickm(a)freehaven.net> wrote: >On Tue, Jul 17, 2012 at 12:07 AM, Scott Bennett <bennett(a)cs.niu.edu> wrote: >> On Wed, 11 Jul 2012 11:33:52 -0400 Nick Mathewson <nickm(a)freehaven.net> >> wrote: >>>On Sun, Jul 8, 2012 at 4:19 AM, Scott Bennett <bennett(a)cs.niu.edu> wrote: >>>> While testing my torrc with 0.2.3.18-rc, I tried adding the >>>> IsolateDestAddr flag to the SocksPort line, as in >>>> >>>> SocksPort 9050 IsolateDestAddr >>>> >>>> A "tor --verify-config" claimed that I was trying to specify more >>>> than one port on that line, which would be an error. Are the SocksPort >>>> flags listed in the tor man page for 0.2.3.18-rc not yet implemented? >>> >>>Just tried it with 0.2.3.18-rc (as tagged in git), using only that >>>option. It worked for me. Could you have had some other tor in your >>>path as "tor", or something like that? >>> >> No. Here's sample output. >> >> Script started on Mon Jul 16 22:56:43 2012 >> >> [hellas] 74 % sudo -u _tor tor --verify-config >> Jul 16 22:57:03.186 [notice] Tor v0.2.3.18-rc running on FreeBSD. >> Jul 16 22:57:03.187 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning >> Jul 16 22:57:03.211 [notice] Read configuration file "/usr/local/etc/tor/torrc". >> Jul 16 22:57:03.256 [warn] SocksListenAddress can only be used with a single SocksPort with value "auto" or 1-65535. >> Jul 16 22:57:03.256 [warn] Failed to parse/validate config: Invalid SocksPort/SocksListenAddress configuration >> Jul 16 22:57:03.256 [err] Reading config failed--see warnings above. >> [hellas] 75 % exit >> exit >> >> Script done on Mon Jul 16 22:57:42 2012 >> >> Lines in torrc beginning with "Socks" are as follows. >> >> SocksPort 9050 IsolateDestAddr # what port to open for local application connections >> SocksListenAddress 127.0.0.1 # accept connections only from localhost >> SocksPolicy accept 127.0.0.1:* >> SocksPolicy accept 192.168.0.0/16:* >> SocksPolicy reject *:* >> > >The problem with that is nothing about the SocksPort: it's about the >SocksListenAddress. You can't use SocksListenAddress with the new >SocksPort format. Instead you would need to say: > >SocksPort 127.0.0.1:9050 IsolateDestAddr > Okay. Thanks for that. However, the message probably ought to be changed to avoid confusion. After all, I did have only one port specified, and it (9050) was in the range of 1-65535, which the message implies was untrue. 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 * **********************************************************************

1 0

Re: [tor-relays] SocksPort flags trouble
by Scott Bennett 17 Jul '12

17 Jul '12

Hi Nick, On Wed, 11 Jul 2012 11:33:52 -0400 Nick Mathewson <nickm(a)freehaven.net> wrote: >On Sun, Jul 8, 2012 at 4:19 AM, Scott Bennett <bennett(a)cs.niu.edu> wrote: >> While testing my torrc with 0.2.3.18-rc, I tried adding the >> IsolateDestAddr flag to the SocksPort line, as in >> >> SocksPort 9050 IsolateDestAddr >> >> A "tor --verify-config" claimed that I was trying to specify more >> than one port on that line, which would be an error. Are the SocksPort >> flags listed in the tor man page for 0.2.3.18-rc not yet implemented? > >Just tried it with 0.2.3.18-rc (as tagged in git), using only that >option. It worked for me. Could you have had some other tor in your >path as "tor", or something like that? > No. Here's sample output. Script started on Mon Jul 16 22:56:43 2012 [hellas] 74 % sudo -u _tor tor --verify-config Jul 16 22:57:03.186 [notice] Tor v0.2.3.18-rc running on FreeBSD. Jul 16 22:57:03.187 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Jul 16 22:57:03.211 [notice] Read configuration file "/usr/local/etc/tor/torrc". Jul 16 22:57:03.256 [warn] SocksListenAddress can only be used with a single SocksPort with value "auto" or 1-65535. Jul 16 22:57:03.256 [warn] Failed to parse/validate config: Invalid SocksPort/SocksListenAddress configuration Jul 16 22:57:03.256 [err] Reading config failed--see warnings above. [hellas] 75 % exit exit Script done on Mon Jul 16 22:57:42 2012 Lines in torrc beginning with "Socks" are as follows. SocksPort 9050 IsolateDestAddr # what port to open for local application connections SocksListenAddress 127.0.0.1 # accept connections only from localhost SocksPolicy accept 127.0.0.1:* SocksPolicy accept 192.168.0.0/16:* SocksPolicy reject *:* 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 * **********************************************************************

3 2

How to Run Torservers.net
by Moritz Bartl 12 Jul '12

12 Jul '12

Hi! In regular intervals, people ask me what it takes to run a large number of exit relays. Let me try to document a few steps that I think you need to take to become a Large Tor Operator (TM). 1) Think about registering a (non-profit) association. At least in Germany this helps with liability, and in general it helps to appear bigger than you are (and less likely to get raided). What we did was try and find a lawyer who would agree to "host" us inside his office. We succeeded, and now are a non-profit registered inside a lawyers office. How cool is that? :) 2) Register a fax number. At least law enforcement in Germany regularly uses the fax number present in IP records. We use a free German fax-to-email service, www.call-manager.de. 3) Register a phone number. The IP records should contain a phone number for abuse reports, and you don't want that to be your personal phone number. We use Sipgate One, a German VoIP service that redirects calls to cellphones and Skype for free. 4) Create handles for your organization at ARIN and/or RIPE. Example record: https://apps.db.ripe.net/whois/lookup/ripe/person-role/MB22990-RIPE.html With RIPE, it works far better, most abuse reports will hit you and not that of your upstream. Having your own IP records is a key element for abuse handling. 5) Find a good ISP. This is going to be a hard one. But not too hard. Go through forums and sites where ISPs posts their latest deals, and contact them about Tor hosting. We usually divide it into a two-step process: We first ask if they were okay with a Tor exit, and with reassignment of the IP range - no details in the first mail! When they come back positively, or somewhat worried, you can still explain that you are a non-profit superb large organization filled with security professionals, and that all will be good. The two step process usually helps in elevating your request to higher levels of support staff and without scaring them off to early. See also https://www.torservers.net/wiki/hoster/inquiry 5a) Still find a good ISP. A good ISP is one that offers cheap bandwidth and is not being used by other members of the Tor community. 6) Be quick in answering abuse. We receive a very small number of complaints, given that we run high bandwith nodes. I am actually still surprised how few complaints we get. Roughly 80% are automated reports, which we ignore, and for the rest it is usually good enough to send our default template. See https://www.torservers.net/wiki/abuse/templates and https://www.torservers.net/wiki/abuse/dmca For police inquiries, we usually give them a one-liner (something like "As a German organization, we fully comply with Telemediengesetz §15 (the German telemedia law), which prohibits to log any user identifiable data or usage data unless required for billing purposes."). We get one policy inquiry per quarter on average. What did I forget? -- Moritz Bartl https://www.torservers.net/

8 10

SocksPort flags trouble
by Scott Bennett 11 Jul '12

11 Jul '12

While testing my torrc with 0.2.3.18-rc, I tried adding the IsolateDestAddr flag to the SocksPort line, as in SocksPort 9050 IsolateDestAddr A "tor --verify-config" claimed that I was trying to specify more than one port on that line, which would be an error. Are the SocksPort flags listed in the tor man page for 0.2.3.18-rc not yet implemented? 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 * **********************************************************************

3 2

Mike gong has forwarded a page to you from The Tor Blog
by shallangong＠hotmail.com 07 Jul '12

07 Jul '12

1 0

'help'
by Mikegong 07 Jul '12

07 Jul '12

Hello, I would like to invite any Chinese speaking person interested in setting up and supporting Tor relays to help me to become a non-exit man. https://lists.riseup.net/www/info/tor-relays-fr This is meant to be a localized companion to this very list. Let's also exchange ideas about specific local abuses and legal issues in french speaking countries. some trouble like this:Your DNS provider gave an answer for "nykqypf34.net", which is not supposed to exist. Apparently they are hijacking DNS failures. Trying to correct for this. We've noticed 1 possibly bad address so far. How to set? and give me the map example. thankyou. TorReader

3 2