- tor-relays - lists.torproject.org

[ANNOUNCE] tor-relays-fr mailing-list
by delber 05 Jul '12

05 Jul '12

Hello, I would like to invite any french speaking person interested in setting up and supporting Tor relays to join to a new mailing-list at: 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. Hope to see you there, -- delber

1 0

Re: [tor-relays] tor-relays Digest, Vol 18, Issue 2
by Christian 04 Jul '12

04 Jul '12

Hi again, so I tried every imho sensitive configuration of ORPorts with different Ports through my router, IPv4Only and without and vice versa and again. No success. What intrigues me is that client functionality is also NOT working and that should be independent from the advertised ports, as far as I know. A time ago, I read about an issue preventing 20 % of the network talking to itself. Could this be related? I mean, as my node stopped talking in gerneral... So I have to wait for better times or an inspiration from your side to get my bridge out of troubled water over it again. Greetings and thanks to everyone considering to think about the issue. And Roger, great work so far. I came to hear concerned people talk about personal implications of societies and politics so different from what I'm used to... It was quite impressing. Greetings 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. Re: tor-relays Digest, Vol 18, Issue 1 (Christian) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 01 Jul 2012 16:50:08 +0200 > From: Christian <brightsidedarkside(a)t-online.de> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] tor-relays Digest, Vol 18, Issue 1 > Message-ID: <1341154208.2712.9.camel(a)delusions.local> > Content-Type: text/plain; charset="UTF-8" > > 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 > > ***************************************** > > > > > ------------------------------ > > _______________________________________________ > 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 2 > *****************************************

1 0

Failed to parse/validate config: failed to bind one of the listener ports
by Christian 01 Jul '12

01 Jul '12

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 > *****************************************

2 1

Guidance on 0.2.2-to-0.2.3 migration?
by Steve Snyder 30 Jun '12

30 Jun '12

Attention Tor developers: Now that v0.2.3 is at Release Candidate status, can we get get some guidance for those relay operators that have not kept up with development? What changes can/should be made to a working v0.2.2 torrc for best 0.2.3 operation? What are the major changes (SMP? IPv6? memory/CPU requirements?) that should be considered when establishing a new relay? Thanks.

3 2

Tor and firewall output rules
by Anton Korec 28 Jun '12

28 Jun '12

Hi, I'm new to this list, so I apologise when my problem has been solved already. I'm runing new tor router as a non-exit relay, with ORPort 443 and DirPort 80. Server is running on Debian stable and tor version is 0.2.2.35. Tor is running under debian-tor user. I have restrictive iptables firewall rules (in both directions, INPUT and OUTPUT). I do not like fw rules of type "all outgoing is allowed". So I set fw up as found somewhere on torproject.org wiki, with "-m owner --uid-owner debian-tor": IPTABLES -P INPUT DROP IPTABLES -P OUTPUT DROP IPTABLES -P FORWARD DROP ... ... IPTABLES -A INPUT -i eth0 -p tcp -s 0.0.0.0/0 --sport 1024: -d ${MYIP} --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT IPTABLES -A OUTPUT -o eth0 -p tcp -s ${MYIP} -d 0.0.0.0/0 -m state --state NEW,ESTABLISHED -m owner --uid-owner debian-tor -j ACCEPT In such configuration fw has been dropping large numbers of packets with uid 0 and packets with no uid set. And it seems that there was almost no tor traffic on relay. So I changed OUTPUT rule to: IPTABLES -A OUTPUT -o eth0 -p tcp -s ${MYIP} -d 0.0.0.0/0 -m state --state NEW,ESTABLISHED -j ACCEPT and everything worked fine. I tried to use 0.2.2.37, 0.2.3.17-beta precompiled deb packages, tried to compile from source downloaded from torproject.org, but packet dropping was the same on every version of tor. Last thing I did, was update fw rules to: IPTABLES -A INPUT -i eth0 -p tcp -s 0.0.0.0/0 --sport 1024: -d ${MYIP} --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT IPTABLES -A OUTPUT -o eth0 -p tcp -s ${MYIP} -d 0.0.0.0/0 -m state --state NEW,ESTABLISHED -m owner --uid-owner debian-tor -j ACCEPT IPTABLES -A OUTPUT -o eth0 -p tcp -s ${MYIP} -d 0.0.0.0/0 -m state --state NEW,ESTABLISHED -j ACCEPT to count packets traversing each OUTPUT rule (with and without uid to "debian- tor" set). 22% of all packets (it is 11% of bytes of that traffic) sent by tor relay was uid not set to "debian-tor". Why is tor sending packets with uid not set to "debian-tor"? Regards Tony

1 0

Failed to parse/validate config: failed to bind one of the listener ports
by Christian 26 Jun '12

26 Jun '12

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

3 3

Traffic stats without vidalia
by Name Withheld 19 Jun '12

19 Jun '12

I've done some searching, but I can't seem to find any references to how I check the traffic stats (current b/w use, total MB passed, etc) for my node when running on a linux (CentOS 6) platform. I've built a new vps with a huge pipe that's command-line-only to maximize performance, but I'm noticing that I can't tell if it's working well without being able to view basic statistical info within that CLI environment. Does anyone know the solution to this? Thank you very much.

3 3

Problems with nameservers and permissions
by George 18 Jun '12

18 Jun '12

I've just started running a relay on Linux with Tor starting automatically, however arm reported that "all nameservers have failed" and, unsure what to do, I stopped Tor to go look up the problem. Then when I tried to start it in Terminal again I'm greeted with this: Jun 18 11:53:15.000 [warn] Couldn't open "/home/george/.tor/lock" for locking: Permission denied Jun 18 11:53:15.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. I've tried changing the permissions of the directory and the lock file but it still says permission denied. What should I do? I'm running Tor 0.2.3.17-beta-1 on Ubuntu 12.04. Thank you for any help, George

1 0

Failed to bind one of the listener ports / V. 2.3.17
by Christian 18 Jun '12

18 Jun '12

Hi all, since the last update from the repositories took place where I replaced the torrc file by the new version, I get the error message indicating no binding to the listener ports. I use Ubuntu lucid and Tor 2.3.17-beta-1~lucid+1 as a bridge. My ORPort section reads as follows: ORPort 443 NoListen ORPort 0.0.0.0:9090 NoAdvertise Am I missing something? I have forwarded external port 443 to port 9090 on my machine on my router. The setup consists of only one machine and the router. It worked well until this afternoon. ;-) I read about a copy and paste issue in config.c on the web, but it had been marked solved in February and doesn't seem to be for non-compilers like me. I really appreciate your kind help and thank you in advance. Greetings, christian

1 0

Tor Network Map advertising available B/W way too low
by Name Withheld 14 Jun '12

14 Jun '12

Hello, I just set up an exit node (PrivacyFoundation on the list), and while I've got 5mbps up, it only advertises as 80-90kb b/w available. That's not at all accurate, and I think it's meaning the connection is ending up way underutilized, since I'm not seeing much traffic on the b/w graph. How do I change the advertised b/w? Thanks!

2 1

running first Relay, low budget VPS on a Gigabit line
by tim 13 Jun '12

13 Jun '12

Hi, I have installed my first Tor-Relay on a low priced test VPS (1 BTC/m) hosted in NL some days ago. Today iftop shows the VPS puts 35 MByte/s in both directions through the line. *Phew* The hosting plan includes 50GB per month so I'm a bit over the fair use. What would you do? Let it run? throttle down? do no harm? Other than expected I only got a short mail with ssh login from them. The answer to my question if customers get some kind of admin-panel was: no, this would be higher security risk. contact us we do it in 2 hours. Any suggestions how to measure the traffic would be appreciated, must be roughly 12 TB the last 2 days. -- http://www.fastmail.fm - Accessible with your email software or over the web

4 4

ARM 1.4.5 has a very high cpu consumption
by tor-admin 10 Jun '12

10 Jun '12

Hi, today I updated arm from 1.4.4.1 to 1.4.5. After this update I noticed that the arm display is very unresponsive. The arm cpu jumps ever couple of seconds up to 90-100 %. If this happens arm does not update its display. This can be observed on all pages. I monitor two high capacity nodes with each about around 10K concurrent connections. With 1.4.4.1 the arm cpu was normally below 5 %. The tor server runs debian squeeze with python 2.6.6. Is this a known issue? Any options other that downgrading back to 1.4.4.1? Regards, Klaus

2 2

rpm init script not setting ulimit properly
by Aaron Hopkins 06 Jun '12

06 Jun '12

I noticed my exit node (tordienet) hovering around 1024 connections open, and checked /proc/<pid>/limits (available on newer kernels) and noticed that the filedescriptor ulimit was at the default 1024, which is likely not a great plan. I'm using the stock /etc/init.d/tor startup script that came in the tor-0.2.3.12.alpha-tor.0.rh5_7 RPM offered by the YUM repo http://deb.torproject.org/torproject.org/rpm/centos5-experimental. It attempts to set ulimit, but at least at startup on my Centos 5.8 openvz container, there's a soft limit set at 1024 filedescriptors, which requires the -S flag to ulimit to override. I changed line 87 of /etc/init.d/tor to: if ulimit -SHn "$MAX_FILEDESCRIPTORS" ; then And /proc/<pid>/limits shows tor running with the appropriate limits now. Unfortunately, this is likely to get reverted with the next package update. Is anyone else using the stock RPMs seeing the same behavior? -- Aaron

1 0

case law on for exit nodes
by Rejo Zenger 28 May '12

28 May '12

Hi, Who knows about cases where the owner of Tor exit node was prosecuted or taken to court for information that was up- or downloaded using his/her Tor node? Basically, I'm looking for case law on running Tor exit-nodes. I am especially interested in case law from countries in Europe, but other examples are most welcome as well. If there is an interesting set of verdicts, I'll compile a summary and I'll share it with this list. Thanks for your help! -- Rejo Zenger . <rejo(a)zenger.nl> . 0x21DBEFD4 . <https://rejo.zenger.nl> GPG encrypted e-mail preferred . +31.6.39642738 . @rejozenger

13 25

Re: [tor-relays] tuning MaxAdvertisedBandwidth for CPU
by Scott Bennett 27 May '12

27 May '12

On Thu, 24 May 2012 13:13:56 -0400 micah anderson <micah(a)riseup.net> wrote: >i've got an exit node that is doing a fair bit of bandwidth, but I think it is CPU bound at this point because I am >getting these: > >Your computer is too slow to handle this many circuit creation requests! Please consider using the >MaxAdvertisedBandwidth config option > >i'm wondering what I should set the MaxAdvertisedBandwidth to if I am averaging this type of traffic: >http://torstatus.blutmagie.de/router_detail.php?FP=131b60b9afe6aea60042132d… > >it seems from the graphs, there are some clear plateaus at around >5100000, but I figured that folks here might have some suggestions that >are better than just setting MaxAdvertisedBandwidth just to that number Before you mess around with MaxAdvertisedBandwidth, which really doesn't work as advertised in the man page, try just adding this to your torrc file: MaxOnionsPending 250 That should take care of the occasional moments when the onion skin queue overflows. 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

New contact info for guard node Austrina
by Samuel Whited 27 May '12

27 May '12

Dear relay operators / users: I operate the guard node Austrina (fp: CA54 C9F2 AA56 FE26 D7A1 6F26 93F6 5385 E85E 2D75) and have recently updated my public key. Any sensitive communications should now use public key 0xEC2C9934 (fp: F259 8DED 56ED E408 FD41 484B FB39 BCF7 EC2C 9934) available from pgp.mit.edu. Please update your keystores, and verify that the new key is cross-signed with the old one (0x0DBB515F). Verification can also be performed via DNS — `dig +short sam._pka.samwhited.com TXT` should give the same fingerprint as above and provide an alternate download location. Contact info on the node should update shortly. Thanks, Sam -- Sam Whited pub 4096R/EC2C9934 SamWhited.com sam(a)samwhited.com 404.492.6008

1 0

tuning MaxAdvertisedBandwidth for CPU
by micah anderson 26 May '12

26 May '12

i've got an exit node that is doing a fair bit of bandwidth, but I think it is CPU bound at this point because I am getting these: Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option i'm wondering what I should set the MaxAdvertisedBandwidth to if I am averaging this type of traffic: http://torstatus.blutmagie.de/router_detail.php?FP=131b60b9afe6aea60042132d… it seems from the graphs, there are some clear plateaus at around 5100000, but I figured that folks here might have some suggestions that are better than just setting MaxAdvertisedBandwidth just to that number thanks! micah --

3 3

too many abuse reports
by mick 23 May '12

23 May '12

Hi I have today, reluctantly, switched my node torofotheworld.aibohphobia.org from an exit node to relay only. My ISP has stayed faithful over several abuse reports in the past, but this week following two more in quick sucession (from brazilian government services by the look of it) they have asked that I shut down the exit policy. Rather than lose the node entirely, I have agreed. Some bozo has been using sqlmap to scan servers through tor. Mick --------------------------------------------------------------------- blog: baldric.net fingerprint: E8D2 8882 F7AE DEB7 B2AA 9407 B9EA 82CC 1092 7423 ---------------------------------------------------------------------

10 19

Configuring a Tor relay to *not* accept torrent traffic
by Red Rover 20 May '12

20 May '12

Hi there, :-) I am running a Tor relay on a VPS. How do I configure it to NOT accept torrent traffic? I have just received an abuse report from my hosting company. All the best, Redrover

3 4

reg : closing circuits and corresponding TLS connections when application terminates
by Sambuddho Chakravarty 19 May '12

19 May '12

Hi all I am playing around with an experimental setup of a private Tor network and I am using the control protocol to setup custom circuits. Before establishing the custom circuits on the Tor client , I set the following options: __DisablePredictedCircuits:1 MaxOnionsPending : 1 newcircuitperiod : 999999999 maxcircuitdirtiness : 999999999 CircuitStreamTimeout : 999999999 CircuitIdleTimeout : 999999999 Thereafter, I turn off existing circuits on the client and establish my own circuit using nodes in my private Tor network. Then the client communicates to a server via this circuit. When the client-server communication ends, the circuit closes by itself. Thereafter, in sometime the corresponding OP-OR connections also close. Is there a way to keep the circuit and/or OP-OR connections alive long after the client-server communication has terminated ? Secondly, I don't see all TLS connections corresponding to the requested circuit in all the relays. Eg. I am using thee hosts -- A, B and C for the private network where, A runs two directory authorities and an OR, while B and C run only ORs. The Tor client of my setup establishes circuit through A, B and C using the above configuration parameters. 'getinfo' reports that the requested circuit has been established but I only see TLS connection betwen A and C..is there a reason why this is the case. Also, in my network, C has no exit policies, while A and B have 'reject *:*' exit policies (just to make sure that all TCP connections exit via C). Thanks Sambuddho

1 0

If you're using OpenSSL 1.0.1, upgrade to 1.0.1c
by Nick Mathewson 11 May '12

11 May '12

Hi, all! If you are using any version of openssl 1.0.1, 1.0.1a, or 1.0.1b, you should know that it's affected by a recent security advisory: https://www.openssl.org/news/secadv_20120510.txt If I am reading the diffs for this bug right, it looks like it would attacker to crash a server remotely. To avoid that, I'd recommend that all Tor nodes running any version of OpenSSL 1.0.1 should upgrade to 1.0.1c. Non-1.0.1 version of OpenSSL have this bug in their DTLS implementations, but Tor doesn't use DTLS. We'll try to get new packages out soon. yrs, -- Nick

1 0

Verizon Abuse Notice from Limited relay
by Michael Millspaugh 10 May '12

10 May '12

Hey all - I've been running a relay here for about 2-3 years now, with limited problems, especially since I switched to the more restrictive reduced exit policy (only allowing a few ports). However, I just received this today, which is new and alarming. I've replied with the boilerplate, but I'm worried as I've never heard from verizon since I went reduced, and they are the fastest and most reliable ISP (fiber to the home) in my part of the states. Here's the message, truncated: On 05-09-2011, your account was reported to have been used in an attempt to gain unauthorized access to another system, or to transmit malicious traffic to another Internet user. It is possible your system may have been infected by a virus or a botnet that is causing this action. Report and/or Logs: Timestamp: 2012-05-09 11:28:55 (GMT) Alert: COSED [CSG-GOP-009] SCAN Sqlmap SQL Injection Scan Source: 96.242.209.159 (49608) Destination: 200.189.113.50 (80) Content: LL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,% 20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,% 20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,% 20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,% 20NULL,%20NULL,%20NULL--%20%20AND%20%27tysA%27%3D%27tysA& codigo=09590039044&orgcom=116100&serie=E000874295&tipo= DEFESA%20PREVIA&result=INDEFERIDO&motivo=015&auto=116100-E000874295 HTTP/1.1 Accept-Encoding: identity Accept-Language: en-us,en;q=0.5 Connection: close Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: sqlmap/1.0-dev (r4997) (http://www.sqlmap.org) Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7 Host: celepar7.pr.gov.br Pragma: no-cache Cache-Control: no-cache,no-store -- TERMS OF USE. By reading this e-mail, you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, terms-of-use, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

3 2

bridge usage summary in vidalia bridge bundle
by eliaz 10 May '12

10 May '12

When I installed Vidalia/Tor from vidalia-bridge-bundle-0.2.2.35-0.2.17, the Bridge Usage Summary the program never appeared. This turned out to be because by default the installed program points to geiop at AppData\Roaming\tor\ . This is incorrect, the file is in AppData\Local\Tor\ . Writing GeoIPFile C:\...\...\AppData\Local\Tor\geoip into torrc fixes this and now the Bridge Usage Summary appears. I don't know if this is just a glitch of my machine (Vista x 64) or if the code needs to be corrected, but I thought I'd report it. By default the bridge bundle places files in three separate folders in AppData\Local\ and Appdata\Roaming\ . Collecting these in one place would make it a bit easier for the user to reconfigure if necessary. - eliaz ---- gpg: 0xE498E90D

1 0

sustained bandwidth drop through noisetor
by Andy Isaacson 04 May '12

04 May '12

noisetor-01 was pushing 300-400 Mbps of traffic from 2012-02-15 through 2012-04-13. Since mid-April we've seen traffic decrease significantly; over the last week, our daily peak has been 260 Mbps (versus 450 Mbps in March) and our daily trough has been 100 Mbps (versus 300 Mbps in March). The traffic levels dropped off in a smooth fashion over a 10 day period, April 15-25 if I read the graphs correctly. There's no sign that anything is amiss on the node; CPU and memory usage are consistently lower, today, than they were in March -- as expected, given the lower utilization. The logs are silent. I've been postprocessing torstatus's Tor_query_EXPORT.csv regularly, and it appears that the overall exit throughput of the network has gone up slightly over the last few months; some new significant nodes came online during 2012Q1 and may have affected the traffic distribution. However, while noisetor has seen a significant drop, other families of exit nodes have seen their bandwidth go up or stay steady. Has there been a change in the routing algorithm, or any other network changes that might explain this drop? Thanks, -andy

3 3

Re: [tor-relays] [tor-dev] Can we stop sanitizing nicknames in bridge descriptors?
by Karsten Loesing 03 May '12

03 May '12

[Cc'ing tor-relays, because this discussion might be relevant for relay/bridge operators, too. Please keep the discussion on tor-dev. See https://lists.torproject.org/pipermail/tor-dev/2012-May/003489.html for the whole thread.] Hi Sebastian, On 5/2/12 9:35 PM, Sebastian G. <bastik.tor> wrote: > [...] > > Do similar names actually mean that bridges are located where the relay > is? (Apparently you've got the data to see these correlations) A fine question. How do we define "similar" and "located where the relay is?" I can see how a relay "bastik1" and a bridge "bastik2" have similar nicknames, but would we also teach a program that "bastikrelay" and "bastikbridge" are similar? And are two IP address in the same, say, /30 located nearby, or is the same /28 or even /24 okay, too? So, while we have the data to see these correlations, I think that whatever similarity algorithm we come up with, somebody else might come up with something smarter. If we do the analysis you suggest and learn that it's safe to include nicknames, that doesn't say very much. Only because we have the data to confirm how well our attack would works doesn't automatically mean we're in a good position to design the attack. If you want to run this analysis with the 2008 tarball (assuming there won't be general objections within the next two weeks), I'm happy to take your list of likely bridge IP addresses and tell you how accurate your algorithm is. > "We don't need it, so better remove it." I really like that. I think we're really conservative with giving out bridge data, and that's good. At the same time there's a value in giving out information about bridges, so that "remove everything" is not a good answer. For example, I think if we give bridge operators better feedback how their bridge is doing, we'll suddenly have a lot more bridges. Making it easy for bridge operators to use Atlas would be a good step into that direction. The same applies to funders who realize from our statistics how successful the Tor Cloud project is and who then want to fund it more to make it more usable, support more cloud providers, etc. >> And are we giving away anything else with the nicknames? > > Maybe it's location ;) > > As I read "hints on the location" for the first time; I though it would > mean that "TowerBridge" or "BridgeofLondon" would be bad since it could > hint to London. Well, in that case you'd learn that there's a (Tor) bridge in London. But that wouldn't help you very much, would it? > Could it make sense to ask the same question on the tor-relay list? Here > you (the Tor people) have more data again and know who subscribed to > both lists. I for myself assume that relay and bridge operators, which > could object, because it's their naming scheme that could reveal > something, are more likely to be subscribed to tor-relays. Good idea. I added tor-relays to the Cc to let relay/bridge operators know. Let's keep this discussion on tor-dev though. >> And if nobody >> screams, I'll provide the remaining tarballs containing original >> nicknames another two weeks later. > > Probably two weeks later, since unpacking, processing and re-packing > takes some time :) I know the sanitized ones are large when they are > unpacked. Windows needs some time to delete the extracted files. Right. :) I'll probably start sanitizing all bridge descriptors at once in two weeks, starting with the 2008 ones, and provide only the 2008 tarball then. It's going to keep my CPU and disks busy for a while. Thanks for your input! Best, Karsten

1 0

Towards a Tor Node Best Best Practices Document
by Mike Perry 01 May '12

01 May '12

It's occurred to me that we have yet to provide any official recommendations with respect to best practices for operating Tor relays. This post is my attempt to define a reasonable threat model and use it to develop some recommendations. My plan is to post it here first, to subject it to review by the relay operator community. After operators have a chance to comment, the plan is to relocate the document to the Tor Wiki and/or a blog post. As always, to focus our thoughts, we start with the adversary's goals. Adversary Goals There is a significant difference between adversaries that can see inside of router-to-router TLS vs those that cannot. I believe this capability distinction governs the adversary goals in terms of compromising relays as opposed to merely externally observing them. Adversaries that can unwrap router TLS can perform every attack that an actual node can perform, at any location between the user and the node, and/or between the node and other nodes. In particular, adversaries that can see inside router TLS can perform tagging attacks (see https://lists.torproject.org/pipermail/tor-dev/2012-March/003361.html) as well as perform circuit-specific active and passive timing analysis. These attacks can be quite severe. An adversary that is able to obtain Guard identity keys is free to perform a tagging attack anywhere on the Internet. In other words, if the adversary is interested in monitoring a particular user, the adversary need only obtain the identity keys for that user's 3 guard nodes, and from that point on, the adversary will be able to transparently monitor everything that user does by way of using tagging to bias the users paths to connect only to surveilled exit nodes who also have had their identity keys compromised. Based on this distinction, it seems that some simple best practices can increase the costs of an adversary that wishes to compromise tor traffic. Let's now consider how the adversary goes about compromising router TLS. Attack Vectors There are two high-level vectors towards seeing inside node-to-node TLS (which uses ephemeral keys that are rotated daily and authenticated via the node's identity key). Both high-level vectors therefore revolve around node identity key theft. Attack Vector #1: One-Time Key Theft The one-time adversary is interested in performing a grab of keys and then operating transparently upstream afterwords. This adversary will take the form of a coercive request at a datacenter/ISP to extract identity node key material and from then on, operate externally as a transparent upstream MITM, creating fake ephemeral TLS keys authenticated with the stolen identity key. Tor nodes that encounter this adversary will likely see it in the form of unexplained reboots/mysterious downtime, which are inevitable in the lifespan of any Tor node. Attack Vector #2: Advanced Persistent Threat Key Theft If one-time methods fail or are beyond reach, the adversary has to resort to persistent machine compromise to retain access to node key material. The APT attacker can use the same vector as #1 or perhaps an external vector such as daemon compromise, but they then must also plant a backdoor that would do something like trawl through the RAM of a machine, sniff out the keys (perhaps even grabbing the ephemeral TLS keys directly), and transmit them offsite for collection. This is a significantly more expensive position for the adversary to maintain, because it is possible to notice upon a thorough forensic investigation during a perhaps unrelated incident, and it may trigger firewall warnings or other common least privilege defense alarms inadvertently. Unfortunately, it is also a more expensive attack to defend against, because it requires extensive auditing and assurance mechanisms on the part of the relay operator. Defenses It seems clear that the above indicates that at minimum relays should protect against one-time key compromise. Some further thought shows that it is possible to make the APT adversary's task harder as well, albeit with significantly more effort. Let's deal with defending against each vector in turn. Prevent Vector #1 (One-Time Key Theft): Deploy Ephemeral Identity Keys The simplest way to defend against the adversary who attempts to extract relay keys through a reboot is to take advantage of the fact that even node identity keys can be ephemeral, and do not need to persist long term (certainly not past a reboot). This can be achieved with a boot script that wipes your keys (they live in /var/lib/tor/keys) at startup, or by using a ramdisk: http://www.cyberciti.biz/faq/howto-create-linux-ram-disk-filesystem/ Of the two, the ramdisk option is superior, since it will prevent the adversary from easily re-using your old keys after you begin using the new ones. Additionally, ssh server key theft is another one-time vector that can be used to quickly bootstrap into node key theft. For this reason, node admins should always use ssh key auth for tor node administration accounts, since it prevents ssh server key theft from implying continuous server compromise: http://www.gremwell.com/ssh-mitm-public-key-authentication Issues With Ephemeral Identity Keys There are a few issues with deploying ephemeral identity keys. Issues With Ephemeral Identity Keys: Client guard node loss The primary issue with ephemeral identity keys is client Guard node loss. If your relay obtains the Guard flag, you should endeavor to keep it. If you have planned maintenance and controlled reboots, you should copy your identity keys to a safe location prior to reboot so that clients aren't forced to rotate their guards prematurely due to unnecessary rekeying. Issues With Ephemeral Identity Keys: MyFamily The next issue is that identity key rotation makes the use of MyFamily very complicated. For large families, it's nearly impossible to update the MyFamily line of each node instance after every unexpected reboot. We've filed a bug to see if we can find a more convenient way to provide the same feature, but it's not clear that MyFamily is worth maintaining: https://trac.torproject.org/projects/tor/ticket/5565 It is very likely that the security benefit from maintaining MyFamily pales in comparison the gain from deploying ephemeral identity keys, and MyFamily should be abandoned entirely. Issues With Ephemeral Identity Keys: Tor Weather The final issue with ephemeral identity keys is that node monitoring mechanisms such as Tor Weather become difficult to use in the face of rotating keys. We've filed this bug to improve Weather's subscription mechanisms: https://trac.torproject.org/projects/tor/ticket/5564 Preventing Vector #2: Isolation Hardening and Readonly Runtime Once one-time key theft has been dealt with, you can begin to consider how to deal with the Advanced Persistent Threat. The effort required to defend against this adversary is considerable, and it is not expected that all operators will devote the effort to do so. To limit scope, we are not going to deal with the daemon compromise vector; for that see your OS least-privilege mechanisms (such as SElinux, AppArmor, Grsec RBAC, Seatbelt, etc). Instead, we will deal with how you can attempt to protect your identity keys once an adversary already has root access. If you are serious about defending against this adversary, the first thing you will want to do is disable access to the 'ptrace' system call from userland, which allows easy key theft using debugging tools. Note that all current built-in kernel mechanisms to do this still allow root users to use ptrace on arbitrary processes. In order to disable ptrace for root users, you need to load a kernel module to patch the syscall table to remove access to the syscall itself. Two options for this are: https://gist.github.com/1216637 http://people.baicom.com/~agramajo/misc/no-ptrace.c Once access to the ptrace system call is removed, you need to disable module loading to prevent it from being restored. On Linux, this is accomplished via 'sysctl kernel.modules_disabled=1'. You should perform this operation as early in the boot process as possible. One technique that works on Redhat-based systems is to place a shell script in /etc/rc.modules to load the modules you need for operation, insert the ptrace module, and then issue the sysctl to disable further module loading. Redhat-derivatives launch /etc/rc.modules first thing at the top of /etc/rc.sysinit. After that comes ensuring runtime integrity. There are several ways to achieve this, but most are easily subverted by an attacker with direct access to the hardware. The most robust approach seems to be to create a small encrypted loopback filesystem that contains all of the libraries required to run the 'tor' process as well as all of the requisite configuration files. Requisite libraries can be determined via 'ldd /usr/bin/tor'. The encrypted loopback filesystem doesn't need to be more than ~25M in size, but you will also need an auxillary var loopback that needs to be a hundred megs or so. Here are the commands for creating the root loopback filesystem: dd if=/dev/urandom of=./tor-root.img bs=1k count=25k losetup /dev/loop1 ./tor-root.img cryptsetup luksFormat /dev/loop1 cryptsetup luksOpen /dev/loop1 tor-root mkfs.ext4 /dev/mapper/tor-root Once this encrypted loop is created such that it can run your relay's Tor processes, you should take the sha1sum of the file and store it offsite. When you use this loopback, you will mount it readonly, and mount an unencrypted var directory inside of it, and a ramdisk for your keys inside of that: dd if=/dev/urandom of=./tor-var.img bs=1k count=200k losetup /dev/loop2 ./tor-var.img mkfs.ext4 /dev/loop2 mount /dev/mapper/tor-root /mnt/tor-root -o ro mount /dev/loop2 /mnt/tor-root/var mkfs -q /dev/ram1 128 mount /dev/ram1 /mnt/tor-root/var/lib/tor/keys cd /mnt/tor-root/ chroot . start_tor.sh Once you start your tor process(es), you will want to copy your identity key offsite, and then remove it. Tor does not need it to remain on disk after startup, and removing it ensures that an attacker must deploy a kernel exploit to obtain it from memory. While you should not re-use the identity key after unexplained reboots, you may want to retain a copy for planned reboots and tor maintenance. scp /mnt/tor-root/var/lib/tor/keys/secret_id_key offsite_backup:/mnt/usb/tor_key rm /mnt/tor-root/var/lib/tor/keys/secret_id_key Upon suspicious reboots, you can verify the integrity of your tor image by simply calculating the sha1sum (perhaps copying the image offsite first). You do not need to do anything special with the var loopback. These steps should prevent even adversaries who compromise the root account on your system (by rebooting it, for example) from obtaining your identity keys directly, forcing them to resort to kernel exploits and memory gymnastics in order to do so. Don't forget to periodically update the libraries stored on your loopback root using a trusted offsite source, as they won't receive security updates from your distribution. One alternative to make your loopback fs creation, tor startup, and maintenance process simpler is to statically compile your image's tor binary on an offsite, trusted computer. If you do this, you should no longer need to bother with chrooting your tor processes or copying libraries around. However, it still does not save you from the need to recompile that binary whenever there is a security update to the underlying libraries, and it may come at a cost of exploit resistance due to the loss of per-library ASLR. Ok, that's it. What do people think? Personally, I think that if we can require a kernel exploit and/or weird memory gymnastics for key compromise, that would be a *huge* improvement. Do the above recommendations actually accomplish that? If so, should we work on providing scripts to make the loopback filesystem creation process easier, and/or provide loopback images themselves? Even the APT defenses end up not working out, I would sleep a lot better at night if most relays deployed only the defenses to one-time key theft... Thoughts on that? -- Mike Perry

3 6

Arm Release 1.4.5
by Damian Johnson 29 Apr '12

29 Apr '12

Hi all. A new release of arm [1] is now available which includes numerous fixes of mounting importance [2]. In particular this corrects several issues around arm's connection panel, terminal glitches due to disruption of the curses module by readline [3], and incompatibility with tor's new development releases [4][5]. This release does not include any new features, nor are any planned in the near future. Most of my attention is going to stem right now [6][7], and my next foray into arm will be to work with Ravi to migrate it to the new library this summer [8]. That said, if you encounter any problems then let me know! -Damian [1] http://www.atagar.com/arm/ [2] http://www.atagar.com/arm/releaseNotes.php [3] https://gitweb.torproject.org/arm.git/commitdiff/b86e5bf [4] https://lists.torproject.org/pipermail/tor-talk/2012-April/023961.html [5] https://trac.torproject.org/projects/tor/ticket/3313 [6] https://gitweb.torproject.org/stem.git [7] https://trac.torproject.org/projects/tor/wiki/doc/stem [8] https://www.torproject.org/about/gsocProposal/gsoc12-proposal-stemImproveme…

1 0

"who has used my bridge" in vidalia bridge bundle?
by eliaz 24 Apr '12

24 Apr '12

After running bridge relays in the TBB for a long time I now get "who has used my bridge" results quite quickly after restarts. But in the stable bridge bundle, this function seems not to work - I've had the bundle running for well over a day and am still getting the msg "no clients have used your relay recently," while the Bandwidth Usage is sailing away to beat the band. Is there a way to fix this? - eli ---- gpg: 0xC3E1E38D

2 4

What to do about icecat.biz abuse complaints?
by Steve Snyder 14 Apr '12

14 Apr '12

I often get abuse complaints from icecat,biz saying that a "RIP attempt" was seen from the IP address of my exit node. Apparently this involves too many connections in a given period of time. I've tried to contact them but get no answer from the e-mail address included in the abuse reports. The Administrator listed in the icecat.biz whois says he just provides the network and can't provide any info about the company or who to contact within it. The abuse reports each say that my IP address will be blacklisted for a week. Fine with me. I'd just as soon they blacklist it forever but as they are unresponsive to e-mail communication I can't tell them that. Short of turning my exit node into a middle node, what can I do about these frequent abuse reports?

5 6

Mystery of bridge utilization
by Steve Snyder 02 Apr '12

02 Apr '12

I've got 2 bridges, with 1 IP address in each of 2 servers in the same geographical area. The IP addresses are not consecutive. Both servers have the same hardware and software configurations. Both were established in mid-January and (excepting a few brief periods of down time) have been running since then. So why then in March did one server handle 200GB of traffic while the other handled only 2GB? (Yes, a x100 difference.) Also: is there something I can do to make my under-utilized bridge more attractive to the Bridge Authorities? Thanks.

3 3

hardware accel option in tor alpha
by Sebastian Urbach 01 Apr '12

01 Apr '12

Hi, I want to use the "hardware accel" feature with the actual tor alpha version 0.2.3.12-alpha1. My CPUs support the Intel AES NI function and the kernel module is enabled and running well. Im running OpenSSL 1.0.1, the debian dev told me that there is no dynamic loadable aes ni shipped though its supporting th function. Im pretty confused about the options int the torrc right now. I have enabled "hardware accel" but did not define any dynamic loadable engine anymore because there is no one according to the debian dev and also the output from "openssl engine". The debug log does not show any enabled aes / evp functions what so ever. Im stuck right now, does anybody have some advice, woudl be awesome ;-) ? Thanks -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

2 3

How does Tor use nameservers?
by Steve Snyder 01 Apr '12

01 Apr '12

I am attempting to load-balance DNS resolution requests. Suppose, in Linux, you have a /etc/resolv.conf with this contents: nameserver aaa.bbb.ccc.ddd nameserver eee.fff.000.111 nameserver 222.333.444.555 How does a Tor exit node use these 3 nameservers? Are they used in a round-robin fashion with the next name resolution request being handled by the next nameserver in rotation? Is the first nameserver ("aaa.bbb.ccc.ddd" above) always used first, with the second being used if the first exceeds some time-out threshold, and the third used only if the first 2 fail? Does a middle node use name resolution at all, or is the relaying based purely on IP addresses? Thanks.

2 1

Questions about exit enclaves
by Jef Heri 31 Mar '12

31 Mar '12

Hello list, I hope this is the correct list to send these questions, if not I apologize and please tell me where I should send this message. I want to setup a Tor node to run as a exit enclave for a web site (WordPress) and message board (vBulletin). However, I have found little documentation on how to accomplish this on a remote server, e.g. https://trac.torproject.org/projects/tor/wiki/doc/ExitEnclave . Is there a more throughout document/manual for exit enclaves? Is it correct that a exit enclave will act as a 'normal' exit node, as well as the exit enclave for its IP address (https://trac.torproject.org/projects/tor/ticket/800)? If so, is it possible to block exit to any IP other than the node's own IP via torrc file? If not, maybe I could only allow exists to white-list IPs, such as Tor Project web site IP, EFF IP, and etc? I believe someone who sends messages to tor-talk maintains a hardened (OS(?) and) Tor, meant to be run as a node only, from remote server space. Does anyone have a link for that software? I looked at the Tor web site but I didn't find information. I am thinking about using that software as the exit enclave. Lastly, is it possible (and smart - re anonymity and resources) to use the exit enclave to offer hidden service address? Thanks!

5 8

Re: [tor-relays] Questions about exit enclaves
by Jef Heri 31 Mar '12

31 Mar '12

Hello Tom and Konstantinos, >>>>> On Mar 30, 2012 14:18:35, "Jef Heri" <jefheri1 at yahoo.com> wrote: >>>>> >>>>> Hello list, >>>>> >>>>> [snip] >>>>> >>>>> Is it correct that a exit enclave will act as a >>>>> 'normal' exit node, as well as the exit enclave for its IP >>>>> address (https://trac.torproject.org/projects/tor/ticket/800)? >>>>> If so, is it possible to block exit to any IP other than the >>>>> node's own IP via torrc file? If not, maybe I could only >>>>> allow exists to white-list IPs, such as Tor Project web site >>>>> IP, EFF IP, and etc? >>>>> >>>>> [snip] >>>>> >>>>> Thanks! >>>> On Mar 30, 2012 14:43:09, "Tom Ritter" <tom at ritter.vg> wrote: >>>> >>>> It's my understanding that if you put the following Exit Policy in your torrc: >>>> >>>> ExitPolicyRejectPrivate 0 >>>> ExitPolicy accept 97.107.139.108 >>>> ExitPolicy reject *:* >>>> >>>> Where 97.107.139.108 is your IP address (that one's mine), you will >>>> Exit Enclave to your site, not allow any other exit traffic, you will >>>> be a normal tor relay (meaning you should check your bandwidth >>>> limits/accounting), and you will become the preferred path for Tor >>>> traffic to your site. >>>> [snip] >>> On 30 March 2012 14:50:49, Konstantinos Asimakis <inshame at gmail.com> wrote: >>> >>> Wouldn't it be safer to accept connections only on port 80? Else he >>> would be exposing the whole machine. >> On 30 March 2012 14:43:09, "Tom Ritter" <tom at ritter.vg> wrote: >> >> Hm. I don't know. If you have a local firewall that blocks access to >> say, samba, from external addresses, but allows it locally - would tor >> allow you to access the port, because it appears that the connection >> from coming locally? >> >> If you're already exposing port 22 on the internet, I would argue >> allowing it through tor exit enclaving isn't increasing your risk any. >> But if tor lets you bypass the firewall - then there's a concern. >> >> -tom > On Mar 30, 2012 15:02:04, Konstantinos Asimakis <inshame at gmail.com> wrote: > > I bet it will bypass the firewall but until someone else answers play it > safe and allow only the ports you need. ;-) Thank you both for the interesting back and fourth. I think I tend to side with Konstantinos, and since my site will only offer SSL (not http), I guess I should setup to only accept connections from 443, correct? Thank you both.

1 0

Re: [tor-relays] Questions about exit enclaves
by Jef Heri 31 Mar '12

31 Mar '12

Hello Tom, --- On Mar 30, 2012 5:43 PM, "Tom Ritter" <tom at ritter.vg> wrote: > > On 03/30/2012 04:18 PM, Jef Heri wrote: > > > > Hello list, > > > > [snip] > > > > Is it correct that a exit enclave will act as a > > 'normal' exit node, as well as the exit enclave for its IP > > address (https://trac.torproject.org/projects/tor/ticket/800)? > > If so, is it possible to block exit to any IP other than the > > node's own IP via torrc file? If not, maybe I could only > > allow exists to white-list IPs, such as Tor Project web site > > IP, EFF IP, and etc? > > > > [snip] > > > > Thanks! > It's my understanding that if you put the following Exit Policy in your > torrc: > > ExitPolicyRejectPrivate 0 > ExitPolicy accept 97.107.139.108 > ExitPolicy reject *:* > > Where 97.107.139.108 is your IP address (that one's mine), you will > Exit Enclave to your site, not allow any other exit traffic, you will > be a normal tor relay (meaning you should check your bandwidth > limits/accounting), and you will become the preferred path for Tor > traffic to your site. Thank you. That was very helpful.

1 0

Bad Exit
by Matthias Bethke 31 Mar '12

31 Mar '12

I was wondering whether anyone could explain me how a node gets the "Bad Exit" flag? The thing is this, my router: http://torstatus.blutmagie.de/router_detail.php?FP=6c7c819f808ac125c69e1d98… As you can see, it has the "Bad Exit" flag even though it's not an exit and hasn't been for months. So I suppose that's something manually assigned? To do with POP/IMAP sniffing honeypots maybe? Seeing that quite a lot of people use unencrypted mail protocols over TOR, I wrote script about a year ago to try and warn them about it: - run ulogd and dsniff to capture logins - try and do a login to the account to see if it succeeded, to see whether it's just an unsuccessful hacking attempt (dsniff doesn't tell me and I was too lazy to write something myself to check the response) - if so, guess the full address. Either it's in the login or if not the server probably serves only one domain anyway and I use the reverse lookup - Send them a mail saying, hey, either you've been doing this yourself and it's a bad idea, or someone stole your credentials and is anonymously snooping around in your mail; in any case, change your password. I suppose someone is doing the reverse and has some fake accounts that they access via TOR and then see if there are any logins that are not theirs to flag the respective exit as a bad guy. Still sounds like a good idea to me but obviously it doesn't work when flagged as bad. Maybe someone can convince me otherwise or has an ide on how to coordinate the two things? Or am I completely off the track here and the reason for the flag is something different? cheers, Matthias

2 1

Exit node and VPN relakks.com
by Jonathan 21 Mar '12

21 Mar '12

Hey all, I have a server in a server farm on a 100mbit symmetrical line... I was looking at relakks.com as a VPN service. Anyone has any experience with these guys? Someone I know use it but only gets up to 2mbit on this line... Anyone has different experiences? I run a relay at home, but wanted to contribute with an exit node on the server as it has a big connection which does not get all fully used at the moment... Thanks, Jon

3 4

Re: [tor-relays] [tor] Re: Hosting relays in the Netherlands
by grarpamp 13 Mar '12

13 Mar '12

[sorry, same note, right tor-relays address this time :-] >> I got to a point where I want to make an active contribution to the >> Tor cause starting with running some nodes of my own, but I'm having >> difficulties on finding hosting companies (vps/dedicated) that allow >> running Tor services. >> >> I know that you've been resuming your servers in the Netherlands >> Would like to hear what's your experience with that. > > There is not much advice I can give you. I do not want to recommend any > of our ISPs, not because we're not happy with them (to the contrary), > but because it makes no sense to put more and more Tor exits into few > places. My strategy always is to find appropriate offers (cheap high > bandwidth) and then contact the ISP. This has evolved into a pretty > standardized two-step approach: First, I ask if they were okay "with > Tor" and reassigning IP space, and telling them that we're security > researchers and that we have worked with many ISPs successfully in the > past. Because the reassignment is somewhat of a special case, this > usually helps in reaching someone higher up in the support chain who can > make such decisions. Once they get back to me, I explain Tor a little > more and only then tell them about the caveats, but reassure them that > we have a volunteer team handling abuse around the clock etc. > > Depending on what you're able and willing to spend, a good approach > would be to look for data centers, and ask there for potential partners. > I wrote a small script that puts the GeoIP location of Tor nodes on a > map, which is somewhat helpful in finding "empty spots". A good idea > would be a script that extracts ASNs, sums up "their" Tor bandwidth, and > then not go with those that already have a high bandwidth exit, but > maybe some other AS in the same datacenters? Yes! Far better to look for new diverse holes and fill them than to essentially duplicate existing nodes. Bringing in tor-relays on this, as this topic comes up there once in a while too. I'll add that AS path info is available from route views looking glasses. Think of it like traceroute, but for BGP. It's quite handy. A node map showing current GEO, AS, and provider would be a cool idea. Lots of cities have datacenters and moms/pops of some sort. People could then find a gap near them, then poke around the phonebook, webhostingtalk, datacentertalk, [NA]NOG's, etc to find a diverse fill.

2 1

Reg : Torperf measurements
by Sambuddho Chakravarty 11 Mar '12

11 Mar '12

Hi all The section on Performance data in the Tor metrics page https://metrics.torproject.org/data.html , says that you are recording data by running Torperf on 'moria', 'torperf' and 'siv'. I know 'moria' is a exit node. But what are 'torperf' and 'siv' ? Tor directory listing doesn't list them.

2 2

pluggable transport proxy
by Scott Bennett 19 Feb '12

19 Feb '12

A recent posting--sorry, but I deleted it before realizing that I had something to say as a followup--referred to proposal #180 (see https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggabl… for the text), and after reading the section titled "Notes on plugins to write", it seemed to me that the first note might be satisfied by tcpproxy with little or no modification. The developers might wish to look at its description at http://www.spreadspace.org/tcpproxy/ It handles IPv4, IPv6, and cross-protocol tunneling, as well as optionally doing remote DNS resolution. FWIW, I like the mentions of possibly allowing the use of such proxies with ordinary relays, too. This might provide an opening to allow unpublished, extra ORPorts of ordinary relays to be distributed and used in a manner similar to bridges. Allowing pluggable proxies for ordinary relays ought also to facilitate development and testing of UDP- and SCTP-based transports for tor in a way that would avoid disrupting existing tor network operation. 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

30% drop in exit throughput since Feb 8
by Andy Isaacson 19 Feb '12

19 Feb '12

Noisetor is showing a significant, sustained drop in bandwidth usage starting approximately February 7-8. We've checked our setup and logs and there doesn't appear to be any sign of a causative factor here. Throughout January and the first week of February we were averaging 400-500 Mbps. There was a pretty smooth decline down on the 8th, stabilizing at a "new normal" of 200-300 Mbps which we've maintained since then. (All these numbers are based on Munin graphs of eth0 throughput using the if_ plugin.) I have some hacky Python that summarizes the torstatus.blutmagie.de data, and it appears that other exits didn't see a similar drop; but our drop came a few hours to days after torservers added a significant amount of new bandwidth. (However, total exit BW reported in torstatus did not increase much; if anything it seems to have gone down slightly.) Around the same time, Amunet rose from ~150 Mbps to ~450 Mbps and has remained in that range since. Thoughts? -andy

3 3

Can bridge run in tiny VPS
by tor-relays＠nickcoleman.org 14 Feb '12

14 Feb '12

After reading on Hacker News about Tor's request for bridges for Syria and Iran, I thought perhaps I could use my el-cheapo VPS for this. I use it to run an anonymous forwarding proxy for my own use. It gets very little use, so I can do without the proxy for a few months. Mem is limited to 128MB, with bursts to 256MB. Bandwidth is 500GB up and down per month. Tor can have half of this (note the up *and* down). The caveat is that, because it is a dirt cheap VPS, I don't get a warning about any violation of the TOS. If I go outside the guidelines, they cancel my account. So I need to be fairly certain, or somehow limit Tor, that its memory use in normal circumstances will not exceed ~100MB. Is it feasible to run a bridge within these limits? If so, any suggestions on config options welcome. thanks, Nick

5 4

HardwareAccel
by Sebastian Urbach 03 Feb '12

03 Feb '12

Hi, Does anyone know how to use the HardwareAccel feature correctly ? Somehow im not able to get this working on my Intel cpus wit the hardware AES engine built in. It would be great to get it up and running because 24 cores could do some nice work for tor ;-) Thanks in advance -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

2 1

reg : problem using the OPAddon script from the torflow package
by Sambuddho Chakravarty 02 Feb '12

02 Feb '12

Hi All I am trying to use the OPAddon script to measure circuit bandwidth. I use the following input configuration for pathrc input configuration: [GENERAL] # Set the host and port where Tor is # listening for control-connections control_host = 127.0.0.1 control_port = 9051 [CIRC_MANAGEMENT] # Size of the maintained pool of circuits idle_circuits = 3 # TODO: Configure ports to use [NODE_SELECTION] # Number of hops to be used in paths and # a minimum-value for advertised bandwidth pathlen = 3 min_bw = 1024 # Percentiles percent_fast = 100 percent_skip = 0 use_all_exits = yes # UniformGenerator with optionally ordered exits, # 'uniform = no' --> bandwidth-weighted selection uniform = no order_exits = no # Make use of guard-nodes (yes|no) or a specific # exit node (nickname or IDHex) for every path use_guards = yes #use_exit = xyz [GEOIP] # Use GeoIP use_geoip = no # yes|no for unique|equal country codes # ! comment out to don't care unique_countries = no # Maximum number of continent crossings: 0-n # ! comment out to enforce distinct continents # ! set >= pathlen to not care about #max_continent_crossings = 2 # Maximum number of ocean crossings: 0-n # ! comment out to don't care #max_ocean_crossings = 1 # If echelon is set, OP-Addon will try to find an # exit in the destination country of the current # request (exit_country may be used as backup) # yes|no # TODO: echelon = yes # Set country codes for single positions #entry_country = DE #middle_country = RU #exit_country = US # TODO: excludes = [".."] [RTT] # Frequently ping the latencies of complete circuits # yes|no ping_circs = no # Tor socks-properties socks_host = 127.0.0.1 socks_port = 9050 ping_dummy_host = 127.0.0.1 ping_dummy_port = 100 # Time interval to wait before triggering # pings and frequency of pings in seconds (float) initial_interval = 10 frequency = 5 # Close a circuit after n timeouts on measurings # Set to 0 to never close circs (int) timeout_limit = 1 [MODEL] # Set to 'yes' to measure latencies of single links # and enable circuit creation from the model # yes|no network_model = no # Min ratio of circs created with the backup-method, # controls growing of the model (float in [0,1]) # 0: no growing # 1: growing only min_ratio = 0.5 # RTT-threshhold in seconds when creating circs (float): # 0: no threshhold, choose from all proposals max_rtt = 0 # Minimum number of proposals to choose from (int) min_proposals = 100 [EVALUATE] # Evaluation mode: close every circuit after measuring performance # yes|no evaluate = yes # Number of latency-tests per circuit (int: 0-n) num_rtt_tests = 1 # Number of bandwidth-tests per circuit (int:0 or 1) # Requires stream-server.pl listening on the same host num_bw_tests = 1 # Total amount of circuits to test (int) num_records = 5 I run op-addon.py with the above config and it terminates throwing the following error pointing to PathSupport.py. WARN[Thu Feb 02 17:45:58 2012]:No event for: 650 STREAM 76 CLOSED 47 128.59.16.165:8041 REASON=DONE Traceback (most recent call last): File "<home directory>/torflow.saved/torflow-3c0dd74/TorCtl/TorCtl.py", line 712, in _eventLoop self._handleFn(timestamp, reply) File "<home directory>/torflow.saved/torflow-3c0dd74/TorCtl/TorCtl.py", line 1337, in _handle1 self._map1.get(event.event_name, self.unknown_event)(event) File "./op-addon.py", line 853, in stream_status_event return self.handle_bw_test(s) File "./op-addon.py", line 823, in handle_bw_test lifespan = stream.lifespan(stream.bw_timestamp) File "<home directory>/torflow.saved/torflow-3c0dd74/TorCtl/PathSupport.py", line 1326, in lifespan return now-self.attached_at TypeError: unsupported operand type(s) for -: 'NoneType' and 'float' NOTICE[Thu Feb 02 17:45:58 2012]:Tor closed control connection. Exiting event thread. Terminated I am not sure how to resolve this ... I am not sure if I am doing something wrong or not... Thanks Sambuddho

1 0

Tor relay system & uptime requirements
by Goulven Guillard 02 Feb '12

02 Feb '12

Hi all, I am considering setting up a tor relay. However my configuration is not powerful and I failed to find precise informations about the hardware system requirements. I believe it would be useful to have such informations in the FAQ, along with graphs of the needed RAM & CPU as a function of the allocated bandwidth. Anyway, I would use a Sheevaplug (Marvell 1.2 GHz CPU, 512 MB DDR2 @ 400 MHz) running Debian Squeeze. It already serves as a small webserver (~200 visits/month, <10 MB bandwidth/month), and 150 MB of RAM are allocated to flashybrid (which helps preserving the SD card life by keeping /var/log/* and such data in RAM and write it down only once in a while). First questions : would it be eligible as a tor relay ? As a tor exit ? Or should I rather go for a bridge ? I guess my bandwidth will be limited by the hardware, how much would you suggest ? On the same network is my personal computer which is much more powerful but down most of the day, so I guess it would be unworthy to make use of it ? I have also thought about using the PC of my parents as a bridge (smaller bandwidth), but again it is online only a few hours a day, would it be worth it ? Thanks. Regards, G.

7 10

0.2.3.10-alpha / .11-alpha
by Sebastian Urbach 02 Feb '12

02 Feb '12

Hi, I was wondering if one of you had a message in the log from 0.2.3.10-alpha which was that he coul not access the AES hardware engine and is using software instead. I upgraded to .11-alpha a day later and the message seems to be gone. Does anybody know how to check if he can access the AES hardware engine now or is the feature just disabled in the new version ? Normally he sould be able to access the feature because the Intel CPUs in the system support it, Thanks in advance -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

1 0

Re: [tor-relays] Thoughts on InspecTor?
by Scott Bennett 02 Feb '12

02 Feb '12

On Thu, 2 Feb 2012 00:25:19 -0500 Roger Dingledine <arma(a)mit.edu> wrote: >On Wed, Feb 01, 2012 at 11:36:57PM -0500, Steve Snyder wrote: >> This application claims to identify bad Tor nodes for the purpose of >> excluding them from use: >> >> http://xqz3u5drneuzhaeo.onion/users/badtornodes/ >> >> Anyone have any thoughts on this? > >In general it is a poor plan to change your routing strategy in a way >that makes you different from most Tor users. If you change it enough, >you end up making a signature for your behavior where an attacker can >say "hey, that's the guy who never uses German relays". The result is >that you harm your anonymity. Nobody has really researched how much harm >comes from how much difference -- and we recommend against doing things >that are poorly understood. > >> The sum of bad-exit-flags (8), > >As far as I can tell, >http://xqz3u5drneuzhaeo.onion/users/badtornodes/overview.html#blocking >are all tiny relays so it doesn't much matter whether you badexit them >(you're probably never going to encounter them in practice anyway). > >For the question of exit relays in Iran, see >https://trac.torproject.org/projects/tor/ticket/4207 >https://trac.torproject.org/projects/tor/ticket/4923 > The latter ticket's discussion section is quite interesting. After reading through it, it seems to me that the problem in Roger's point C would be best dealt with in vidalia without regard to IP address or presumed country. When asking whether the user wishes to run a relay, vidalia's dialog could include an instruction something like this: "Before you decide to run a tor relay, please consider whether the government of the country where you live and/or would like to operate a relay might target you for any kind of abuse if that government noticed that you were running a tor relay." As long as the people who have volunteered to provide translations for vidalia's and/or tor's textual interactions with users have sufficient skills to provide such a cautionary note in all of the most necessary languages plus two or three languages spoken widely around the world, then that should take care of the matter. I share the concerns of both Roger and Sebastian regarding undesirable potential results of automating the rejection of entire countries of relays. 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

Thoughts on InspecTor?
by Steve Snyder 02 Feb '12

02 Feb '12

This application claims to identify bad Tor nodes for the purpose of excluding them from use: http://xqz3u5drneuzhaeo.onion/users/badtornodes/ Anyone have any thoughts on this? The sum of bad-exit-flags (8), exit nodes that alter payload (4), and long-term-misconfigured (27) suggests excluding 39 nodes within the Tor config file. Is this reasonable? Are these exclusions appropriate for relays, or for end users, or neither, or both?

2 1

torrc "permission denied" warning
by tony 26 Jan '12

26 Jan '12

In the Tor logs for a relay, I get the following message: Dec 19 19:42:23.662 [notice] Renaming old configuration file to "/etc/tor/torrc.orig.1" Dec 19 19:42:23.662 [warn] Couldn't rename configuration file "/etc/tor/torrc" to "/etc/tor/torrc.orig.1": Permission denied I've played around with file permissions but it doesn't help. Tor seems to be working. Does the error matter? Running Tor on a Ubuntu Server 10.04 LTS Feedback much appreciated.

3 2

This is what you get....compile problem OSX10.4
by Geoff Down 24 Jan '12

24 Jan '12

Can anyone help with this please? % sudo ./configure --with-libevent-dir=/opt/local/lib/ && make && make install -> checking for libevent directory... configure: WARNING: We found the libraries for libevent, but we could not find the C header files. You may need to install a devel package. % port contents libevent ->Port libevent contains: /opt/local/bin/event_rpcgen.py /opt/local/include/evdns.h /opt/local/include/event.h /opt/local/include/event2/buffer.h /opt/local/include/event2/buffer_compat.h /opt/local/include/event2/bufferevent.h /opt/local/include/event2/bufferevent_compat.h /opt/local/include/event2/bufferevent_ssl.h /opt/local/include/event2/bufferevent_struct.h /opt/local/include/event2/dns.h /opt/local/include/event2/dns_compat.h /opt/local/include/event2/dns_struct.h /opt/local/include/event2/event-config.h /opt/local/include/event2/event.h /opt/local/include/event2/event_compat.h /opt/local/include/event2/event_struct.h /opt/local/include/event2/http.h /opt/local/include/event2/http_compat.h /opt/local/include/event2/http_struct.h /opt/local/include/event2/keyvalq_struct.h /opt/local/include/event2/listener.h /opt/local/include/event2/rpc.h /opt/local/include/event2/rpc_compat.h /opt/local/include/event2/rpc_struct.h /opt/local/include/event2/tag.h /opt/local/include/event2/tag_compat.h /opt/local/include/event2/thread.h /opt/local/include/event2/util.h /opt/local/include/evhttp.h /opt/local/include/evrpc.h /opt/local/include/evutil.h /opt/local/lib/libevent-2.0.5.dylib /opt/local/lib/libevent.a /opt/local/lib/libevent.dylib /opt/local/lib/libevent.la /opt/local/lib/libevent_core-2.0.5.dylib /opt/local/lib/libevent_core.a /opt/local/lib/libevent_core.dylib /opt/local/lib/libevent_core.la /opt/local/lib/libevent_extra-2.0.5.dylib /opt/local/lib/libevent_extra.a /opt/local/lib/libevent_extra.dylib /opt/local/lib/libevent_extra.la /opt/local/lib/libevent_openssl-2.0.5.dylib /opt/local/lib/libevent_openssl.a /opt/local/lib/libevent_openssl.dylib /opt/local/lib/libevent_openssl.la /opt/local/lib/libevent_pthreads-2.0.5.dylib /opt/local/lib/libevent_pthreads.a /opt/local/lib/libevent_pthreads.dylib /opt/local/lib/libevent_pthreads.la /opt/local/lib/pkgconfig/libevent.pc /opt/local/lib/pkgconfig/libevent_openssl.pc /opt/local/lib/pkgconfig/libevent_pthreads.pc I'm flying blind here - should libevent be a binary or just a load of source files? I've only a vague idea of what the error messages mean, let alone how to fix them. GD -- http://www.fastmail.fm - A no graphics, no pop-ups email service

4 15