- tor-relays - lists.torproject.org

Re: [tor-relays] reading the captchas
by eliaz 11 Feb '14

11 Feb '14

On 2/10/2014 9:37:23 AM, Lunar (lunar(a)torproject.org) wrote: > eliaz: > > Would it be possible for someone to change the captcha images at the > URL > > for getting bridges, without of course lessening their effectiveness? > > The present ones are pretty much unreadable, to this human at least. - > eliaz > > The issue is already tracked, see: > https://trac.torproject.org/projects/tor/ticket/10809 > -- > Lunar <lunar(a)torproject.org> Thanks for the pointer & your work. I see it's more complicated than I thought. Hope it gets fixed soon, magnifying the screen isn't of much help. I'm reluctant to suggest the page to people as long as reading the captchas is so difficult. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

1 0

High speed exit
by Craig C-S 10 Feb '14

10 Feb '14

Hi all, I've been running a few fail relays over the past few years. All relays I run they begin with the prefix "Telos". I've recently come across a really good deal http://www.soyoustart.com/ca/en/ on hosting..., and begun hosting "TelosTor" and "TelosTor2" from 192.99.8.96. I would welcome any comments on security. At the moment I do not have a stable IP to access them, so have defaulted to 1/min IP access for OpenSSH. I would relish the TOR communities feedback in order to further secure my tor exit node. Thanks! Craig

8 10

Relay bandwidth
by Tora Tora Tora 09 Feb '14

09 Feb '14

I have configured Tor with the following (with daily accounting): RelayBandwidthRate 384 KB RelayBandwidthBurst 512 KB I always assumed that the burst bandwidth will set the maximum relay bandwidth. However, by using iftop, I can see individual connections with speeds as high as 2+ Mbps. Even when individual connections are not exceeding burst speeds, adding up bandwidth of all connections would probably exceed allowed relay burst bandwidth. Is this because Tor is using up the bandwidth allowance, since it is well below its long-time average or is this something unexpected that should not be happening?

4 5

using Arm to manage nodes
by jason＠icetor.is 08 Feb '14

08 Feb '14

Hello all, This is something that's bothered me for quite some time. I often use arm (https://www.torproject.org/projects/arm.html.en) for monitoring my relays and to keep a quick eye on things like overall bandwidth consumed, traffic stats and my favorite client locale statistics. I run it in a screen session and often when I re-attach the session often the keymapping is all messed up and the arrow keys will offer to close arm. Usually it will correct after I shift-m to get to the menu and switch around a few times. Has anyone else experienced this and how did you solve it? -Jason

6 8

Re: [tor-relays] Trying Trusted Tor Traceroutes
by Sebastian Urbach 08 Feb '14

08 Feb '14

Hi, That's odd, please send us your ip address and we will look into this and get back to you asap. Feel free to send me your ip by private mail if you feel more comfortable. I would suggest that you keep running the script, we will check your submitted data and then we go from there. -- 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 Hi, I've seen this error message twice now within about 12 hours: ssh_exchange_identification: Connection closed by remote host If I read the script correctly, it tries to upload the data and then deletes it without checking for successful upload. Since the data is probably lost, should I start over? Best regards, Alexander --- PGP Key: 0xC55A356B | https://dietrich.cx/pgp On 2014-02-07 22:05, Sebastian Urbach wrote: > Dear list members, > The Trying Trusted Tor Traceroutes project is coming closer to the > next data review (03/2014). > Basically every relay (except Bridges) can help to evaluate the Tor > Routes. Please consider that one complete run takes about 4 days with > the default settings. > It's really easy to participate, just download and run the script ! We > are currently at 82 completed runs and i think 100 is a great > milestone :-) > The project website: > http://web.engr.illinois.edu/~das17/tor-traceroute_v1.html > The scoreboard with the results: > http://datarepo.cs.illinois.edu/relay_scoreboard.html > Thank you for your help ! > -- > 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 > _______________________________________________ > 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

1 0

Checking a bridge
by Martin Kepplinger 08 Feb '14

08 Feb '14

When my bridge uses only the same few MBs each day, i guess it isn't used at all right? Is there a simple way to ensure it is in bridgeDB and functioning as it should? thanks, martin

8 8

Trying Trusted Tor Traceroutes
by Sebastian Urbach 08 Feb '14

08 Feb '14

Dear list members, The Trying Trusted Tor Traceroutes project is coming closer to the next data review (03/2014). Basically every relay (except Bridges) can help to evaluate the Tor Routes. Please consider that one complete run takes about 4 days with the default settings. It's really easy to participate, just download and run the script ! We are currently at 82 completed runs and i think 100 is a great milestone :-) The project website: http://web.engr.illinois.edu/~das17/tor-traceroute_v1.html The scoreboard with the results: http://datarepo.cs.illinois.edu/relay_scoreboard.html Thank you for your help ! -- 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

6 6

Onion address or clearnet address
by Hang 07 Feb '14

07 Feb '14

Some sites such as RiseUp and DuckDuckGo could be accessed via onion addresses. I would like to know which address (onion address vs clearnet address) should I use when using TBB. I believe both ways are more or less the same in terms of identity protection and communication security (provided that the clearnet addresses are using HTTPS). Perhaps the main difference is using the clearnet addresses adds burden to the exit relays, while using onion addresses only consumes bandwidth of middle relays which is relatives more in supply. Am I right? Do I overlook anything? Or it doesn't matter at all for either way? Best Hang

4 5

duplicated log output after SIGHUP
by Scott Bennett 07 Feb '14

07 Feb '14

I made a minor change to my torrc file and sent tor a SIGHUP. The only logging I'm doing is "notice" level to a file. Here's what has been going on since the SIGHUP. Feb 06 22:32:01.201 [notice] Heartbeat: Tor's uptime is 10 days 3:00 hours, with 206 circuits open. I've sent 8.22 GB and received 7.72 GB. Feb 06 22:32:01.201 [notice] Average packaged cell fullness: 77.286% Feb 06 22:32:01.201 [notice] TLS write overhead: 12% Feb 06 23:10:33.967 [notice] Received reload signal (hup). Reloading config and resetting internal state. Feb 06 23:10:33.967 [notice] Read configuration file "/usr/local/etc/tor/torrc". Feb 06 23:10:33.976 [warn] Skipping obsolete configuration option 'MaxOnionsPending' Feb 06 23:10:33.978 [notice] Tor 0.2.4.20 (git-3cb5c70beec5bf46) opening log file. Feb 06 23:10:33.978 [notice] Tor 0.2.4.20 (git-3cb5c70beec5bf46) opening log file. Feb 06 23:10:34.293 [notice] Your Tor server's identity key fingerprint is 'MYCROFTsOtherChild 023220505A550D6FDF0C20FF7C48E66BA06A49A6' Feb 06 23:10:34.293 [notice] Your Tor server's identity key fingerprint is 'MYCROFTsOtherChild 023220505A550D6FDF0C20FF7C48E66BA06A49A6' Feb 06 23:31:59.200 [notice] Circuit handshake stats since last time: 2129/2129 TAP, 364/364 NTor. Feb 06 23:31:59.200 [notice] Circuit handshake stats since last time: 2129/2129 TAP, 364/364 NTor. Feb 06 23:32:01.222 [notice] Heartbeat: Tor's uptime is 10 days 4:00 hours, with 296 circuits open. I've sent 8.55 GB and received 8.05 GB. Feb 06 23:32:01.222 [notice] Heartbeat: Tor's uptime is 10 days 4:00 hours, with 296 circuits open. I've sent 8.55 GB and received 8.05 GB. Feb 06 23:32:01.222 [notice] Average packaged cell fullness: 77.276% Feb 06 23:32:01.222 [notice] Average packaged cell fullness: 77.276% Feb 06 23:32:01.222 [notice] TLS write overhead: 11% Feb 06 23:32:01.222 [notice] TLS write overhead: 11% Feb 07 00:31:59.201 [notice] Circuit handshake stats since last time: 2781/2781 TAP, 348/348 NTor. Feb 07 00:31:59.201 [notice] Circuit handshake stats since last time: 2781/2781 TAP, 348/348 NTor. Feb 07 00:32:01.201 [notice] Heartbeat: Tor's uptime is 10 days 5:00 hours, with 384 circuits open. I've sent 8.62 GB and received 8.11 GB. Feb 07 00:32:01.201 [notice] Heartbeat: Tor's uptime is 10 days 5:00 hours, with 384 circuits open. I've sent 8.62 GB and received 8.11 GB. Feb 07 00:32:01.201 [notice] Average packaged cell fullness: 77.264% Feb 07 00:32:01.201 [notice] Average packaged cell fullness: 77.264% Feb 07 00:32:01.201 [notice] TLS write overhead: 11% Feb 07 00:32:01.201 [notice] TLS write overhead: 11% Feb 07 01:31:59.219 [notice] Circuit handshake stats since last time: 3469/3469 TAP, 278/278 NTor. Feb 07 01:31:59.219 [notice] Circuit handshake stats since last time: 3469/3469 TAP, 278/278 NTor. Feb 07 01:32:01.202 [notice] Heartbeat: Tor's uptime is 10 days 6:00 hours, with 559 circuits open. I've sent 8.63 GB and received 8.13 GB. Feb 07 01:32:01.202 [notice] Heartbeat: Tor's uptime is 10 days 6:00 hours, with 559 circuits open. I've sent 8.63 GB and received 8.13 GB. Feb 07 01:32:01.202 [notice] Average packaged cell fullness: 77.151% Feb 07 01:32:01.202 [notice] Average packaged cell fullness: 77.151% Feb 07 01:32:01.202 [notice] TLS write overhead: 11% Feb 07 01:32:01.202 [notice] TLS write overhead: 11% Feb 07 02:31:59.200 [notice] Circuit handshake stats since last time: 4090/4090 TAP, 345/345 NTor. Feb 07 02:31:59.200 [notice] Circuit handshake stats since last time: 4090/4090 TAP, 345/345 NTor. Feb 07 02:32:01.201 [notice] Heartbeat: Tor's uptime is 10 days 7:00 hours, with 540 circuits open. I've sent 8.82 GB and received 8.31 GB. Feb 07 02:32:01.201 [notice] Heartbeat: Tor's uptime is 10 days 7:00 hours, with 540 circuits open. I've sent 8.82 GB and received 8.31 GB. Feb 07 02:32:01.201 [notice] Average packaged cell fullness: 77.116% Feb 07 02:32:01.201 [notice] Average packaged cell fullness: 77.116% Feb 07 02:32:01.201 [notice] TLS write overhead: 11% Feb 07 02:32:01.201 [notice] TLS write overhead: 11% And so on. Is the duplication of messages after a reload a known bug? Please note that the double logging I reported earlier has been corrected by commenting out the --Log stuff in /usr/local/etc/rc.d/tor, so the new double logging appears to be a different problem. 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 * **********************************************************************

1 1

What is more necessary: Bridge or Relay?
by an.to_n-73＠riseup.net 05 Feb '14

05 Feb '14

Hello List! Since 7/2013 I operate a small Tor Server as internal relay or as obfuscated bridge. What is more necessary: An internal relay to speed up the network, or an obfuscated bridge to help censored users? My ISP gives me dynamic IPs, which change daily. I guess this is good for bridges, because my IP is valid only for one day. Otherwise I've got an upload > 500 kbps and could contribute to the network speed. Actually I've got not clue about the need for anonymous bridges. In addition: I could combine both, because my VPN provider iVPN offers port forwarding. So I could run the RaspberryPi as bridge on my own IP and the 2nd server as internal relay over the VPN. So the public relay runs on another IP. But actually the VPN connection terminates by itself, the relay goes offline and I can fix it the evening. => Has anyone experience with servers listening over VPN? Does anyone know more? Best regards Anton -- an.to_n-73(a)riseup.net Public PGP key fingerprint 5FD2 DE00 1B1A 1970 8D32 A59E 4A25 3CE1 A82F F4C4

2 1

http://torstatus.blutmagie.de/
by K. Besig 05 Feb '14

05 Feb '14

Why shouldn't I be concerned when, by simply accessing this page, all my actual ip/dns information is readily available to all?

4 4

Middle relay
by Tora Tora Tora 05 Feb '14

05 Feb '14

I am trying to run a middle relay with no-exit policy. It was my assumption that a middle relay would only communicate with other relays on 9001 port. Yet I see my relay IP address attempting connections to other IP address on ports that are non-9001 (or 9030).

3 5

Bridge or Relay
by Sebastian Urbach 05 Feb '14

05 Feb '14

Hi, I really wonder why we even bother to have a FAQ: http://torproject.org/docs/faq.html.en#RelayOrBridge -- 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

2 1

Phishy
by phrag 04 Feb '14

04 Feb '14

FYI: Just got this to my Tor relay mail address, with a zip file attached extracting to a '.scr' win exe. Curiously routed via a .gov.uk mail relay... GB03022014.scr: PE32 executable (GUI) Intel 80386, for MS Windows MD5: dba1e52929f6ca9d1a1bf87e4ff469cf GB2546241.zip MD5: fb1141494829b144b0075035022cfbb9 GB03022014.scr Samples available on request. Full mail headers attached. ========== From defeats871(a)richszabo.com Mon Feb 03 14:06:39 2014 Return-path: <defeats871(a)richszabo.com> Received: from [217.109.27.97] (helo=WNACDHPXR) Received: from mail1.bemta14.messagelabs.com by server.justinarcher.net Received: from gateway-102.energis.gsi.gov.uk (HELO mx.hosting-w.gsi.gov.uk) (62.25.106.208) by server-10.tower-205.messagelabs.com X-Env-Sender: gateway.confirmation(a)gateway.gov.uk From: <gateway.confirmation(a)gateway.gov.uk> To: <tor(a)phra.gs> Subject: Your Online Submission for Reference 485/GB2546241 Could not process Date: Mon, 3 Feb 2014 22:16:02 +0100 The submission for reference 485/GB2546241 was successfully received and was not processed. Check attached copy for more information. This is an automatically generated email. Please do not reply as the email address is not monitored for received mail. ==========

4 3

Re: [tor-relays] Phishy
by Jesse Victors 03 Feb '14

03 Feb '14

> FYI: Just got this to my Tor relay mail address, with a zip file > attached extracting to a '.scr' win exe. Curiously routed via a .gov.uk > mail relay... > > GB03022014.scr: PE32 executable (GUI) Intel 80386, for MS Windows > > MD5: dba1e52929f6ca9d1a1bf87e4ff469cf GB2546241.zip > MD5: fb1141494829b144b0075035022cfbb9 GB03022014.scr > > Samples available on request. Full mail headers attached. I read Jurre's analysis, but I disagree. I could be mixing this up with something else, but if I recall correctly, that screensaver Trojan Horse trick was one method by which the government was de-anonymizing Tor users, though I don't recall the exact name of this attack vector. Your IP of your relay is public of course, but if you opened that a location/identity that you wanted to stay hidden, in my opinion I would consider that to be compromised. Thanks for the report.

1 0

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 28 Jan '14

28 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 28 Jan '14

28 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