tor-relays February 2014

tor-relays@lists.torproject.org

72 participants
60 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays February 2014