August 2016 - tor-relays - lists.torproject.org

Do middle nodes create multiple connections to the same Exit node? (with different source port)
by don.gould＠tuta.io 15 Aug '16

15 Aug '16

Hello, Do middle nodes create multiple connections to the same Exit node? (with different source port) The reason I ask is because I am a little confused. Even the tor relay operators are completely honest and don't log anything, the ISP / upstream ISP could still log all the connections. So they can see: [MiddleNode IP]:[Source Port] ==> [ExitNode IP]:[Dest Port (ORport)] -- Timestamp + Duration of connection. So if I create a long running ssh connection that is going for 6 hours this will be unique to the middle node. During this 6 hours, if another tor client chooses the same MiddleNode + ExitNode, does the MiddleNode create a new connection to the ExitNode? (Can be found out using netstat) Or does it use the same connection that it already has established with the exit node? Thanks.

2 1

High speed Tor relay advice
by i3 15 Aug '16

15 Aug '16

Hi all, I've ran multiple Tor relays before but I have moved to a new server and would like some advice. My new server has 10Gb/s connection (I've observed it at 900MB/s to the drives) with plenty of CPU and RAM to complement. I typically use default configurations on my relays but I feel that to get the most out of this one I'll need to do some configuration to tweak it. Does anyone have advice on getting the most out of this server, in terms of speed? Thanks

10 14

90% of exits vulnerable to TCP off-path attack
by starlight.2016q3＠binnacle.cx 14 Aug '16

14 Aug '16

RFC-5961 CVE-2016-5696 http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_comm… FYI all

5 4

How to exclude a CDN ?
by Toralf Förster 13 Aug '16

13 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Got few times an informal report containing something like: It is most likely the attack traffic is directed at one of the following endpoints: account.sonyentertainmentnetwork.com auth.np.ac.playstation.net auth.api.sonyentertainmentnetwork.com auth.api.np.ac.playstation.net I was just wondering how would somebody handle a request to exclude those IP addresses, b/c 2 attempts to get the affected netwrok gives: # host account.sonyentertainmentnetwork.com account.sonyentertainmentnetwork.com is an alias for account.sonyentertainmentnetwork.com.edgekey.net. account.sonyentertainmentnetwork.com.edgekey.net is an alias for e380.b.akamaiedge.net. e380.b.akamaiedge.net has address 104.109.72.158 # whois 104.109.72.158 | grep CIDR CIDR: 104.64.0.0/10 CIDR: 104.109.64.0/20 and at another system : ~/devel/wireshark $ host account.sonyentertainmentnetwork.com account.sonyentertainmentnetwork.com is an alias for account.sonyentertainmentnetwork.com.edgekey.net. account.sonyentertainmentnetwork.com.edgekey.net is an alias for e380.b.akamaiedge.net. e380.b.akamaiedge.net has address 184.24.193.168 $ whois 184.24.193.168 | grep CIDR CIDR: 184.24.0.0/13 CIDR: 184.24.192.0/20 - -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAleqBwUACgkQxOrN3gB26U7YXQD+PHgO8nVRo01abzdu1P7zC6TZ gDMkb+L51zt/k7hBJOsA/0czdSd8p8AnINKx+FP2Gi5ZSjVzzBuUM9o+htw5BdIX =Tz+I -----END PGP SIGNATURE-----

4 5

Re: [tor-relays] 90% of exits vulnerable to TCP off-path attack
by starlight.2016q3＠binnacle.cx 13 Aug '16

13 Aug '16

At 12:01 8/12/2016 -0400, Zack Weinberg wrote: >Also, if you read the paper, raising the global rate limit (as >suggested by the reg. article) doesn't help; it only slows the >attacker down a little. The paper indicates that a global counter limit other than 100 can be easily discovered. However the recommended mitigation effectively removes the global counter by setting it to 10^9. The described attack requires the counter be exhausted inside the temporal bounds of one second and the Internet as it exists today cannot support 10^9 probes on that deadline. IMO the recommended mitigation is effective and should be applied by those believing RFC-5961-as-presently- implemented changes worse than the weaknesses addressed by the RFC. I applied the mitigation.

2 1

90% of exits vulnerable to TCP off-path attack
by starlight.2016q3＠binnacle.cx 12 Aug '16

12 Aug '16

[one last time, no DKIM for Tor lists nevermore] RFC-5961 CVE-2016-5696 http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_comm… FYI all

2 1

Re: [tor-relays] 90% of exits vulnerable to TCP off-path attack
by Tristan 12 Aug '16

12 Aug '16

According to Ark Technica ( http://arstechnica.com/security/2016/08/linux-bug-leaves-usa-today-other-to…) encrypted communications can only be blocked, meaning that exit servers could still be targeted. However, the bug only has to affect 1 side in order to work. So even if every exit node patched it, Tor users (and the regular Internet) would still be vulnerable until the Web servers patch it as well. Either way, it'll be a while before everyone is patched. On Aug 12, 2016 11:01 AM, "Zack Weinberg" <zackw(a)cmu.edu> wrote: On Fri, Aug 12, 2016 at 11:27 AM, <starlight.2016q3(a)binnacle.cx> wrote: > RFC-5961 > CVE-2016-5696 > http://www.theregister.co.uk/2016/08/10/linux_tor_users_ open_corrupted_communications/ > FYI all Tor's use of TLS _should_ mean that the worst an attacker can do here is denial-of-service. The Register article suggests that they might also be able to force the use of specific exit relays (by disrupting connections that don't go through those relays) but weaponizing that against specific users (rather than everyone trying to use an exit the attacker doesn't like) strikes me as nontrivial. Also, if you read the paper, raising the global rate limit (as suggested by the reg. article) doesn't help; it only slows the attacker down a little. Right now I think one should not panic and should wait for the kernel people to do a proper fix. zw _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

90% of exits vulnerable to TCP off-path attack
by starlight.2016q3＠binnacle.cx 12 Aug '16

12 Aug '16

[second try here for clean DKIM authentication] [listsrv added a two spaces instead of one] RFC-5961 CVE-2016-5696 http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_comm… FYI all

1 2

Out of memory: Kill process (tor)
by Tristan 12 Aug '16

12 Aug '16

Last night I received my first abuse complaint on DigitalOcean. When I logged in, I saw Tor was no longer running because the system ran out of memory. Is it possible the system ran out of memory because of the abuse? My relay has 512MB of RAM running Tor and Unbound, and it's been running fine all month. How can I prevent this memory issue from happening in the future? Thanks -- Finding information, passing it along. ～SuperSluether

2 1

running a relay on a pi/pi2 and it stopped working after upgrading to 0.2.8.6/0.2.8.6-2 ? read this (bugfix)
by Hack-Tic 10 Aug '16

10 Aug '16

Hi, I ran into some tor restart loop issues after upgrading to 0.2.8.6 on my pi2 relay. In short, it takes too long to read router_parse_list_from_string and hits the systemd start timeout limit causing a restart (and loop) Full story in the ticket here: https://trac.torproject.org/projects/tor/ticket/19819 quick fix: edit /lib/systemd/system/tor(a)default.service and change TimeoutStartSec= from 120 to 300 Hope i'm not "spamming" the list, just trying to help. Have a good one.

4 4