- tor-relays - lists.torproject.org

New GPG key for Runa A. Sandvik
by Runa A. Sandvik 02 Feb '14

02 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi everyone, Tomorrow is my first day as a staff technologist at the Center for Democracy and Technology in Washington, D.C. I will continue to contribute to the Tor Project in one way or another. This new key will be used to sign email from me going forward. The new key is attached and is also available on the keyservers (with a signature from my old key) at: http://pgp.mit.edu/pks/lookup?op=get&search=0x094D46E2898DB6D5 Here's the fingerprint and current subkey information for reference: pub 4096R/898DB6D5 2014-02-02 Key fingerprint = BEBA DB46 6778 5EF9 B00E D141 094D 46E2 898D B6D5 uid Runa A. Sandvik (offline long term identity key) <runa.sandvik(a)gmail.com> uid Runa A. Sandvik (offline long term identity key) <runa(a)cdt.org> uid Runa A. Sandvik (offline long term identity key) <runa(a)torproject.org> sub 3072R/AC8C6CF6 2014-02-02 [expires: 2015-02-02] sub 3072R/FC71640D 2014-02-02 [expires: 2015-02-02] - -- Runa A. Sandvik -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJS7qvsAAoJECgKOvb8cWQNT1UL/joI4P1++EIUPmudw179o+j3 4FxEV32snfYNwW9NTaQNwGODglu7EMZRQ4V1UhytXUb9P7taT0eDgiJxPIvC8Okw xZ7jmk5UnV+R37rMLuhcX1Ifwg3Z+tG0qAwJAbFhO/zZX3yTx+ZJoQBjZ4pX5SFQ qE5G7IeLUrWEAIZfm6mLp3M/kh/+8+e5MPsxrdywo9iLi3Y2IB9mO5VVb94qA5Ul l0ETWilusa9PNRD70jtWhQL6EjPS1tkKVbMFk04naDLr+74gwFAta38tJcnZtPId jZXhqpfqcxD0muaEwyvGtV2qfAxbDuDPDxVJofMeK5S5GESOe4AqLyrkMf4MPz4Z ifKFguKpYAiA4Hz9+v4AoZPhX1Zu33AV/4gfE/Q4ZHq3DtqzEkcyzvvEw9kL0pk+ lJC7+R58dJiJ7pGedG9ZCyJugyp6pujiD34RppPL90JxnP5s3V11VkBiv5ZEnB+k kvBq94TkyFD8bUncFhmh4ilkloPDOrqMcfYGl1VjGg== =KZvl -----END PGP SIGNATURE-----

1 0

Ubuntu is killing tor when getting low memory
by toxi roxi 02 Feb '14

02 Feb '14

Hi Folks, im running many relays which are doing a nice job. But i have also some smaller relays outside which have just 256mb. They are performing quite quell - but on one relay im facing issues which i think you may help me. this relay seems to ran out of memory from time to time (2 to 5 days) and i found out via dmesg, that ubuntu itself is killing the process to free up memory. the swap is used, but far away from full. as this stops tor immediately its bit annoying that i need to restart the releay without any reason. is there any way to tell ubuntu or to prevent that the tor process is killed for freeing up memory? i dont care about other processes as this machine is for tor purposes only. thanks for your expertise! Geri

2 3

Tails 0.22.1~rc1
by K. Besig 31 Jan '14

31 Jan '14

Is anyone having luck setting up a mid-relay within the latest Tails build? I'm finding no joy..

3 3

Re: [tor-relays] Considering setting up an exit, need advice
by Jesse Victors 31 Jan '14

31 Jan '14

> Have you set AccountingMax in your torrc, by chance? > > Also, you sure are restarting the relay a lot. You should learn how to > use 'service reload' rather than 'service restart'. :) No, I don't have AccountingMax enabled, which is one of the reasons why I was puzzled by the hibernation flag. Thanks for the tips on the service, I should have known better. I was restarting often because I was making adjustments to the DirPort and the hosted webpage (that .png thumbnail never loaded when it was offered locally, so I just linked to the hosted one on torproject.org) and it took a few tries before things were working right. Well, at least I won't be restarting Tor frequently going forward. Thanks. >> 3) There are mysterious warnings in the log: >> >> Jan 30 23:07:29.000 [warn] EXTEND cell received, but not via >> RELAY_EARLY. Dropping. [4 similar message(s) suppressed in last 3600 >> seconds] >> Jan 30 23:07:29.000 [warn] (We have dropped 95.24% of all EXTEND cells >> for this reason) > You don't happen to have set "ProtocolWarnings 1" in your torrc, have you? > >> I'm familiar with the meaning of the "EXTEND" cell, but I'm not sure >> what RELAY_EARLY is > See > https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/110-avoid-in… > as motivated by > http://freehaven.net/anonbib/#congestion-longpaths > > My guess is that these are unofficial Tor clients you're seeing, and > you're seeing them more because all official Tor clients are ignoring > your relay until it gets out of 'phase one' (from the blog post). Yes, I had ProtocolWarnings enabled, good eyes there. I had it on because I thought that it would help me see Tor-level security threats, but I think it's better with it off at least for now. Thanks for the help. Jesse

1 0

Re: [tor-relays] Considering setting up an exit, need advice
by Jesse Victors 31 Jan '14

31 Jan '14

Thanks again guys for the help. "usuexit" is now online, and should be functioning properly, but there seem to be a few mystifying issues: 1) TorStatus marks it as "hibernating" which it clearly isn't; it's online and accepting connections. I'm not sure what made TorStatus think it was offline. 2) For the first nine hours it has moved about 12 MB of data. I would think it would be more than that, especially for an exit. There's a blog post outlining the growth rate for guards, but how about for exits? 3) There are mysterious warnings in the log: Jan 30 21:57:36.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 50/50 NTor. Jan 30 22:57:36.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 31/31 NTor. Jan 30 23:07:29.000 [warn] EXTEND cell received, but not via RELAY_EARLY. Dropping. [4 similar message(s) suppressed in last 3600 seconds] Jan 30 23:07:29.000 [warn] (We have dropped 95.24% of all EXTEND cells for this reason) Jan 30 23:57:36.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 39/39 NTor. Jan 31 00:01:41.000 [warn] Got headers "HEAD / HTTP/1.0\r\n\r\n" with unknown command. Closing. Jan 31 00:57:36.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 41/41 NTor. Jan 31 01:04:46.000 [warn] EXTEND cell received, but not via RELAY_EARLY. Dropping. Jan 31 01:04:46.000 [warn] (We have dropped 95.45% of all EXTEND cells for this reason) I'm familiar with the meaning of the "EXTEND" cell, but I'm not sure what RELAY_EARLY is, nor do I know what this warning means. If the relay has an exit policy, why are circuits being extended beyond it? Hidden services, maybe? Basically the log has more warnings in it than it should (at least based on my experience with regular relays) and I'm not sure why. I tried restarting Tor, but the warnings still appeared. Any ideas on what I can do about them, if anything? Thanks, Jesse

2 1

Using syslog for monitoring bridges
by Andreas Fritzel 30 Jan '14

30 Jan '14

Hey all, In two different countries I run 3 Tor bridges for a while now. For monitoring, I want to quit using the local filesystem for storing files, filled by syslog and be able to store the syslog info on a remote system. This is done easily with rsyslog[1], but I want to store it at home without the link between the three bridges and my home IP. So, I was thinking about sending it with rsyslog over TCP to a Tor Hidden Service. Is there anyone who can help me out with this? I was thinking about using SOCKS, but it didn't work out :(. Andreas [1] http://www.rsyslog.com/doc/manual.html

6 5

Problems with domestic ISP blocking publicly listed relays
by Paul Blakeman 29 Jan '14

29 Jan '14

Hi all Wondered if anybody could help out/advise as to what’s happened here… I’m based in UK and have domestic internet with Virgin Media. This service is fibre optic based - config: 30Mbps d/l & 2Mbps u/l [mine is the SLOWEST package!] Last year I finally configured a Dell server (running Debian 7.3 - wheezy) to run a Tor relay (0.2.3.25) Everything has been running fine except for the last few weeks I’ve noticed a few irregularities. The first one has been Tor itself where I have noticed (using Arm to monitor) that it has been downloading far more data than uploading. A ratio of say 5:1 — it hasn’t always been this way! The other is my general difficulty in accessing certain web sites online (that once worked) e.g. Access to lovefim.com this weekend has now resulted in no longer able to stream and watch films. I can log onto system but if I try and stream I get the error message “INVALID LOCATION. Sorry, but the requested content is not available in your current location.” Opened a service desk ticket but the response was “you are trying to stream from outside the UK” WTF????? My IP provided by my ISP has been the same all this time (82.42.215.16) I have spoken with them I would have to switch off for 48hrs and MAY NOT (in fact I was told “probably not”) be assigned a different one! SO… Can using a Tor relay result in your IP getting a “bad” flag? Is there anyway of running a relay where you “hide” your IP? Any advise would be greatly appreciated. Best wishes, Paul

6 7

which browser for BSD systems?
by Scott Bennett 29 Jan '14

29 Jan '14

I'm about a year behind on reading this list, so in the event that my question has been addressed during that time, please forgive me for skipping ahead to the present. In the past week, I have *finally* managed to upgrade from FreeBSD 8.2 to 9.2 and am now slogging through the rebuilding of all my installed ports. The ancient version of firefox that I had been stuck with due to later versions' memory allocation bugs now no longer works. For the moment, I have built firefox 26, but because there is no longer a version of torbutton to be found for love or money from anywhere I'd trust, I'd really like to install something safer than just firefox with NoScript, AdblockPlus, Better Privacy, and a couple of other add-ons. The tor project's web site still has no browser available for the {Dragonfly,Free,Net,Open}BSD, so what I'd like to know is which browser and security add-ons can the tor community recommend for use with tor? Thanks in advance for any clues. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *or* bennett at freeshell.org * *--------------------------------------------------------------------* * "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 * **********************************************************************

4 8

TTTT scoreboard
by Sebastian Urbach 28 Jan '14

28 Jan '14

Dear list members, The scoreboard mentioned above is now displaying the data from the first transmission ever made and from the last one ever made. Until a few hours ago it was just the data from the first run no matter what was done afterwards. This was a problem from the "we never expected multiple runs" era. It's kind of great that bugs are occurring because you are submitting data from multiple runs ;-) ! Please feel free to check it out: http://128.174.241.211:443/relay_scoreboard This is a project were literally every run counts. If you want to help, visit the project site and join us: http://web.engr.illinois.edu/~das17/tor-traceroute_v1.html It seems that there will be a data review in 03/2014, so it would be great to have enough data to actually draw some conclusions this time. Thanks for your support ! -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ---------------------------------------------- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. ---------------------------------------------- Benjamin Franklin (1706 - 1790), Inventor, journalist, printer, diplomat, and statesman

1 0

0.2.4.20 logging duplicate messages
by Scott Bennett 28 Jan '14

28 Jan '14

Along with my recent OS upgrade I have also updated my tor relay from 0.2.4.3-alpha to 0.2.4.20. The latter version write two identical copies of every message to the log file. I have only one uncommented "Log " line in my torrc, which is Log notice file /var/log/tor/notices.log but every single message is getting written to the file twice. Jan 27 19:31:58.213 [notice] Tor 0.2.4.20 (git-3cb5c70beec5bf46) opening log file. Jan 27 19:31:58.214 [notice] Tor 0.2.4.20 (git-3cb5c70beec5bf46) opening log file. Jan 27 19:31:58.220 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip. Jan 27 19:31:58.220 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip. Jan 27 19:31:58.325 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6. Jan 27 19:31:58.325 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6. Jan 27 19:31:58.360 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Jan 27 19:31:58.360 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Jan 27 19:31:58.513 [notice] Your Tor server's identity key fingerprint is 'MYCROFTsOtherChild 023220505A550D6FDF0C20FF7C48E66BA06A49A6' Jan 27 19:31:58.513 [notice] Your Tor server's identity key fingerprint is 'MYCROFTsOtherChild 023220505A550D6FDF0C20FF7C48E66BA06A49A6' Jan 27 19:32:00.387 [notice] We now have enough directory information to build circuits. Jan 27 19:32:00.387 [notice] We now have enough directory information to build circuits. Jan 27 19:32:00.388 [notice] Bootstrapped 80%: Connecting to the Tor network. Jan 27 19:32:00.388 [notice] Bootstrapped 80%: Connecting to the Tor network. Jan 27 19:32:01.399 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. Jan 27 19:32:01.399 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. Jan 27 19:32:01.815 [notice] Bootstrapped 85%: Finishing handshake with first hop. Jan 27 19:32:01.815 [notice] Bootstrapped 85%: Finishing handshake with first hop. Jan 27 19:32:02.287 [notice] Bootstrapped 90%: Establishing a Tor circuit. Jan 27 19:32:02.287 [notice] Bootstrapped 90%: Establishing a Tor circuit. Jan 27 19:32:03.671 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Jan 27 19:32:03.671 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Jan 27 19:32:03.672 [notice] Bootstrapped 100%: Done. Jan 27 19:32:03.672 [notice] Bootstrapped 100%: Done. Jan 27 19:32:03.672 [notice] Now checking whether ORPort 67.175.219.175:32323 and DirPort 67.175.219.175:32326 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Jan 27 19:32:03.672 [notice] Now checking whether ORPort 67.175.219.175:32323 and DirPort 67.175.219.175:32326 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Jan 27 19:32:06.509 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jan 27 19:32:06.509 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jan 27 19:32:07.093 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Jan 27 19:32:07.093 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Jan 27 19:32:25.752 [notice] Performing bandwidth self-test...done. Jan 27 19:32:25.752 [notice] Performing bandwidth self-test...done. Jan 27 19:33:02.567 [notice] We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits pending. Waiting until some finish. Jan 27 19:33:02.567 [notice] We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits pending. Waiting until some finish. Jan 27 20:32:01.397 [notice] Heartbeat: Tor's uptime is 1:00 hours, with 7 circuits open. I've sent 2.93 MB and received 7.98 MB. Jan 27 20:32:01.397 [notice] Heartbeat: Tor's uptime is 1:00 hours, with 7 circuits open. I've sent 2.93 MB and received 7.98 MB. Jan 27 20:32:01.397 [notice] Average packaged cell fullness: 87.404% Jan 27 20:32:01.397 [notice] Average packaged cell fullness: 87.404% Jan 27 20:32:01.397 [notice] TLS write overhead: 9% Jan 27 20:32:01.397 [notice] TLS write overhead: 9% Jan 27 20:32:02.394 [notice] Circuit handshake stats since last time: 25/25 TAP, 13/13 NTor. Jan 27 20:32:02.394 [notice] Circuit handshake stats since last time: 25/25 TAP, 13/13 NTor. ...and so on. Is there some way to stop this behavior and get only a single copy of each message? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *or* bennett at freeshell.org * *--------------------------------------------------------------------* * "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 * **********************************************************************

4 4