- tor-relays - lists.torproject.org

Repeated warning in an exit relay
by livak 18 Sep '18

18 Sep '18

The relay repeatedly casts the following message: Sep 18 08:19:58.000 [warn] Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending) What does it mean ? Livak Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 2

maha's tor-latest on COPR?
by renke＠mobtm.com 18 Sep '18

18 Sep '18

Hi *, does anyone know if maha still supports his Fedora/Epel repo for the latest Tor release[1]? I'm nearly sure he announced his repo on the list some time ago, but I don't find the mail anymore... With 0.3.3.10 (and 0.3.4.8) released and not really happy with compiling it myself[2] an up to date repo for redhattish distributions would be very nice. Thanks Renke [1] https://copr.fedorainfracloud.org/coprs/maha/tor-latest/ [2] too lazy :)

3 2

A bug or a feature ?
by livak 18 Sep '18

18 Sep '18

The ORPort option of torrc was changed fom 9030 to 80, the relay was sent a HUP signal: kill -HUP [PID] and exited with: Sep 18 07:59:04.000 [notice] Received reload signal (hup). Reloading config and resetting internal state. Sep 18 07:59:04.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Sep 18 07:59:04.000 [notice] Read configuration file "/etc/tor/torrc". Sep 18 07:59:04.000 [notice] Opening Directory listener on 0.0.0.0:80 Sep 18 07:59:04.000 [warn] Could not bind to 0.0.0.0:80: Permission denied Sep 18 07:59:04.000 [notice] Closing no-longer-configured Directory listener on 0.0.0.0:9030 Sep 18 07:59:04.000 [warn] Failed to parse/validate config: Failed to bind one of the listener ports. Sep 18 07:59:04.000 [err] Reading config failed--see warnings above. For usage, try -h. Sep 18 07:59:04.000 [warn] Restart failed (config error?). Exiting. When the relay was manually restarted and it successfully ran. Can it be considered a bug ? Livak Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

Torservers relay family decreased?
by Tobias Westerhever 18 Sep '18

18 Sep '18

Hello, recently, I noticed some strange aspects related to networks of Torservers/Zwiebelfreunde. Since there was no way to get any further information on this topic so far, I am posting it here. Maybe someone can help. (a) Torservers relay family decreased? The organisation used to maintain much more relays than their family [1] currently contains. At the moment, only four relays located in NL belong to them, while the Metrics page indicates some orphaned family members. This coincidences with [2], but I am unaware of any announcements of Torservers/Zwiebelfreunde itself (i.e. tight financial situation). Does anybody have further details here? (b) Who is the operator behind family B771AA877687F88E6F1CA5354756DF6C8A7B6B24 ? There are some /24 IPv4 BGP allocations claiming to belong to the umbrella organisation "Zwiebelfreunde e.V.", which operate(d|s) the relay family mentioned above. I will ask further questions about this in (c) . However, there is a _huge_ relay family (27 members, with a total bandwith of ~ 1,245 MB) located in 185.220.101.0/24 , which uses Zwiebelfreunde as a contact role and has not been changed since 2017-09-08. The relays itself, however, all use <abuse(a)to-surf-and-protect.net> as contact address (which does not seem to be related to Zwiebelfreunde at all) and use a description beginning with "nifty". Since most of them have both Guard and Exit flag assigned, I figure they are handling a huge consensus weight. Does anybody know the person/organisation behind them? Are they related to Zwiebelfreunde/Torservers? What is the physical location of the servers (BGP claims DE, but upstream AS200052 uses UK)? (c) Strange BGP allocations using Zwiebelfreunde as contact role At the moment, 9 IPv4 BGP prefixes with a length of /24 are known to use a contact role pointing to Zwiebelfreunde [4] . These are as follows: - 37.218.246.0/24 (Upstream AS47172 "Greenhost", claims EU, but is likely NL, 0 Tor relays found) - 193.235.207.0/24 (Upstream AS196689 "Digicube", claims EU, but is likely FR, 0 Tor relays found) - 192.36.61.0/24 (Upstream AS60781 "Leaseweb", claims EU, but is likely NL, 0 Tor relays found) - 192.36.41.0/24 (Upstream AS34305 "BaseIP", claims EU, but is likely NL, 0 Tor relays found) - 192.36.27.0/24 (Upstream AS60729 "Zwiebelfreunde" !, claims EU, physical location unknown, 0 Tor relays found) - 185.220.102.0/24 (Upstream AS60729 "Zwiebelfreunde" !, claims EU, physical location unknown, 0 Tor relays found) - 185.220.101.0/24 (Upstream AS200052 "Joshua Peter McQuistan", claims DE, physical location unknown, 27 Tor relays found) What puzzles me here is: 1. None of these networks has any Tor relays known (or Metrics does not show them), which is strange as Torservers/Zwiebelfreunde is more or less dedicated to operate relays. 2. The appearing relays solely belong to the strange and huge family mentioned in (b) , which cannot be exactly pinpointed to be run by Torservers/Zwiebelfreunde. 3. I suspected the mentioned IP ranges to be fakely allocated, but most of them were not changed for more than half a year. Further, I never observed any traffic from or to these networks. If anybody does, please drop me a line. 4. All for relays which do belong to Torservers are located in AS43350 ("NForce Entertainment") and do not have their own IPv4 prefix. *** As of these coincidences, and the observations mentioned in (a) and (b), I suspect something nasty (or highly unusual) is going on, but I have no clue what this might be. It would be great if someone who is in Tor more deeply than I am could take a look at this. Also, if there is further information available, please tell me. "Mit dem Wissen wächst der Zweifel. / Doubt grows with knowledge." -- Goethe Best regards, T. Westerhever Links: [1] https://metrics.torproject.org/rs.html#search/family:0FF233C8D78A17B8DB7C82… [2] https://blog.torservers.net/20180704/coordinated-raids-of-zwiebelfreunde-at… [3] https://metrics.torproject.org/rs.html#search/family:B771AA877687F88E6F1CA5… [4] https://bgp.he.net/

8 12

New exit node
by livak 18 Sep '18

18 Sep '18

Just wanted to tell I could set up a new relay with fingerprint Akbash 7C5032CF2545636FEECCE1065A25944FF49C09F7 The relay is been running for more than a day and gathered the Exit, Fast, Running, V2Dir and Valid flags. However this hardworking relay would not continue its earnest efforts unless it could find a wealthy and amenable sponsor. Livak Sent with [ProtonMail](https://protonmail.com) Secure Email.

12 21

Exit friendly ISPs
by grarpamp 17 Sep '18

17 Sep '18

On 9/17/18, niftybunny <abuse(a)to-surf-and-protect.net> wrote: > [cost, cost, cost] >> freedom is a profitable business model. We charge double and up rates to ignore and manage everything, short of legal process served, with you on point in role until you're not. Exits, torrents, gaming, IRC, shells, free speech, social nets, researchers, political sites, any legal business... all fine... bring it. Who's in? >>> reputation costs >> >> So these ISPs get a bad reputation mark on the list of >> bad isp's, on forums, on lists, etc. > > No, they don’t. We (the Tor people) are a tiny fraction of a tiny fraction > of a tiny fraction. Nobody really cares about us. Opinion: RIMU hosting sucks. Why: Because they refuse to host legal exits, or state / negotiate any upstream terms regarding them. Changepoint: When they do either or both of those. There, that should search rank before long. > They have 1 Million websites hosted, who cares > about 2-3 people complaining they do not host Tor exists? If that was an ISP's ratio they'd have much bigger things to deal with, and efficiences in dealing with them, than to care about banning a handful of exit customers. Absent prohibition in law or upstream contract, most ISP's banning such things simply haven't done much to develop and... >> Explore the possible.

2 1

New TOR Relay
by Kyle Levy 17 Sep '18

17 Sep '18

Hello, I am attempting to set up a TOR relay on my raspberry pi on my home network (nickname: relaydetour). I had it set up and running, but now it seems to be offline. I hadn't changed any settings, and it's still flagged as "running" and "valid". Is it functional? And is it more likely a problem with my configuration or something more problematic? Please let me know. Thank you.

4 6

Exit friendly ISPs in Australia
by Isaac Grover, Aileron I.T. 17 Sep '18

17 Sep '18

Good evening, Following up with a tongue-in-cheek suggestion to set up exit nodes in Australia, for those who are interested, there are already seven exit nodes in Australia per https://hackertarget.com/tor-exit-node-visualization/ . I have also contacted RIMU Hosting, which has servers in Australia, and they said "As an account holder under our terms of use, you would be directly responsible for all content in and out of your server. In general that is not possible to do with a tor exist node, so we are not a good fit for that use case." Make your day great, Isaac Grover, Senior I.T. Consultant Aileron I.T. - "Practical & Proactive I.T. Solutions" O: 715-377-0440<tel:715-425-0440>, F:715-690-1029<tel:715-690-1029>, W: www.aileronit.com<http://www.aileronit.com/> LinkedIn: https://www.linkedin.com/in/IsaacGrover/ YouTube: https://www.youtube.com/channel/UCqrwZNFKdR-guKtuQzFPObQ

7 8

Tor master exits with a required protocol error
by teor 17 Sep '18

17 Sep '18

(CC'd tor-relays, please direct replies to tor-dev.) Hi, If you are running Tor master, your Tor may exit with a required protocol error. The issue was introduced in commit 991bec67ee (about 8 hours ago). The following conditions will make Tor exit: * Tor will exit on startup if it has a cached consensus from the 14th of September (or earlier). It does not matter how old the consensus is. * If certain directory authorities go down, the remaining authorities may generate a consensus that will cause your Tor to exit. These consensuses require the LinkAuth=1 protocol, which Tor master believes it does not support. (The change was intended for NSS Tors, but mistakenly applies to all Tors.) Here's how you can mitigate this issue: * downgrade to 0.3.4.8 or earlier, or * delete the cached consensuses in your data directory. These consensuses may be called cached-consensus, cached-microdesc-consensus, unverified-consensus, and unverified-microdesc-consensus. Some may not be present. We should resolve this issue in master in the next 24 hours. Then it may take another 24 hours for packages to be rebuilt. The master ticket for this change is: https://trac.torproject.org/projects/tor/ticket/27288 T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ----------------------------------------------------------------------

1 0

Australian relays
by Sydney 17 Sep '18

17 Sep '18

Hi all I currently run 3 Australian exits, and 1 non-exit, in the 262E84A99F53AE1F6860267F7C5DA5B96E57A46D family. Due to personal reasons I need to take the relays down, which is disappointing as they are currently in a unique AS. This will leave 6 Australian exits. I appreciate that Australia is a long way in terms of latency, and my relays have been fairly under-utilised even though they’re on a 100mbit (Adelaide) and gigabit (Sydney) network interface. I might be in a position to bring these back in 2019. Before I do, I just wanted to know if it’s worthwhile having the Australian relays as part of the network? Cheers Sydney

2 1