- tor-relays - lists.torproject.org

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 16 Sep '18

16 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 16 Sep '18

16 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

Announcement: Relay operator meetings on IRC
by Colin Childs 16 Sep '18

16 Sep '18

Hello Tor relay operators! Starting September 11th @ 1:00AM UTC, we will be piloting regular relay operator meetings in #tor-relays on irc.oftc.net. These meetings will be an opportunity to introduce yourself to the operator community, make new contacts and provide updates to the group on the status of your relays. This will also be an opportunity to have questions answered by a group of dedicated relay operators, community members and Tor Project staff. For everyone overseas, we will be hosting a second meeting on September 25th @ 19:00 UTC. After these initial two meetings, we will evaluate if these dates / times need to be adjusted, as well as how frequently these meetings should be run. I will send a follow-up email at the end of September with the results of that evaluation. On the Monday of meeting weeks, I will send a reminder on this list with the channel, date and time. I look forward to seeing you all there, and thank you for running relays!

6 8

exit operators: overall DNS failure rate above 5% - please check your DNS
by nusenu 16 Sep '18

16 Sep '18

Dear Exit relay operators, first of all thanks for running exit relays! One of the crucial service that you provide in addition to forwarding TCP streams is DNS resolution for tor clients. Exits relays which fail to resolve hostnames are barely useful for tor clients. We noticed that lately the failure rates did increase again and would like to urge you to visit Arthur's "Tor Exit DNS Timeouts" page that shows you the DNS error rate for exit relays: https://arthuredelstein.net/exits/ (the page is usually updated once a day) Please consider checking your DNS if your exit relay consistently shows a non zero timeout rate - and make sure you run an up to date tor version. If you are an exit operator but have no (or no working) ContactInfo, please consider updating that field in your torrc so we can reach you if something is wrong with your relay. kind regards nusenu -- https://twitter.com/nusenu_

2 3

[release] ExoneraTor 4.0.0
by Karsten Loesing 14 Sep '18

14 Sep '18

Good evening, today we released and deployed version 4.0.0 [0] of the ExoneraTor service [1]. This new version greatly reduces database size and variance of query response times. Changes in this version are heavily based on work done by Sebastian Hahn. Earlier ExoneraTor databases can be migrated by running the new psql script [2] that comes with a migration function. Please direct comments and questions to the metrics-team mailing list [3]. All the best, Karsten [0] https://dist.torproject.org/exonerator/4.0.0/ [1] https://metrics.torproject.org/exonerator.html [2] https://gitweb.torproject.org/exonerator.git/tree/src/main/sql/exonerator2.… [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

3 3

Torservers relay family decreased? (solved)
by niftybunny 13 Sep '18

13 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. Lets recap this for a moment: 1. Every relay of my family has my e-mail. Write an e-mail and ask. Problem solved. 2. The e-mails are running on a domain, registered my me, make a whois lookup for the domain. Problem solved. 3. The /24 IP space is registered by me. Make a RIPE (or whoever provides IP lookup) and you also have my name. Problem solved. 4. Ask someone from Torservers about me. They gave me the /24 for hosting Tor exits. Problem solved. 5. Take a look at the Tor relay mailing list, I was active there. Problem solved. 6. I am an registered InterExchangeCarrier under German law. Ask the Bundesnetzagentur for my Information. Problem solved. 7. The RIPE entries are maintained by F3Netze/Zwiebelfreunde. Ask Tim about me. Problem solved. 8. Write a snail mail letter to my address. Problem solved. 9. Send me a facsimile to my official RIPE abuse records. Problem solved. and the list goes on and on … Welcome to the Interwebs where people ask who you are ... To perfect sum it up: https://i.imgur.com/20wmhNT.jpg › (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. There is still no family fingerprint. We did not ever claimed to belong to Zwiebelfreunde e.V. Stop making shit up. › 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. No, we do not. We are the ADMIN-C and the TECH-C. Zwiebelfreunde is just the MNT-REF. Look it up for yourself: https://apps.db.ripe.net/db-web-ui/#/query?bflag&searchtext=185.220.101.0&s… It even has a fucking disclaimer on it: netname: MK-TOR-EXIT remarks: ----------------------------------- remarks: This network is used for Tor Exits. remarks: We do not have any logs at all. remarks: For more information please visit: remarks: https://www.torproject.org remarks: ----------------------------------- remarks: Dieses Netz hostet nur Tor remarks: Exists. Wir haben keinerlei Logs. remarks: Mehr Informationen unter: remarks: https://www.torproject.org The (current) owner of the IPs is: https://apps.db.ripe.net/db-web-ui/#/lookup?source=ripe&key=ORG-MK113-RIPE&… and the abuse contact: https://apps.db.ripe.net/db-web-ui/#/lookup?source=RIPE&key=ACRO11287-RIPE&… › The relays itself, however, all use <abuse at 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". Have you tried to send uns an e-mail and ask? No? They are not related to Zwiebelfreunde because we are not Zwiebelfreunde. And btw, its Nifty + name of a rodent. Yes, I know hedgehogs are no rodents. But they are cute too. › Since most of them have both Guard and Exit flag assigned, I › figure they are handling a huge consensus weight. No. Complete bullshit. Exit flag indicates thats an Exit and Guard indicates a longer uptime. I can make an relay on a wee DSL line with these flags. It indicates not a huge consensus weight at all. RTFM! › Does anybody know the person/organisation behind them? Yes. › Are they related to Zwiebelfreunde/Torservers? Besides the /24, no. What is the physical location of the servers (BGP claims DE, but upstream AS200052 uses UK)? NL BGP claims DE? BGP is a routing protocol, it claims nothing. It doesnt give a flying shit about countries. It routes packets between different ASs. Show me the BGP routing table. › (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) BGP still claims shit. BGP is still a routing protocol. Look at a looking glas server and start reading RTFs. › 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. https://nusenu.github.io/OrNetStats/ https://metrics.torproject.org/rs.html › 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. Yeah, these strange and huge relays are here for over 3 years, growing. https://imgur.com/1jwtxHX Nusenu twitter page, https://twitter.com/nusenu_ , you should check it out. › 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. Yes! Complete right! You just destroyed our super secret FBI/NSA/BND/MI6 plan to take over the Tor network. Good job, Sherlock! › 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. 100% perfect conclusion. Good job, Sherlock! › 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 https://imgur.com/JG514ja › Best regards, › T. Westerhever Whatever, niftybunny

4 5

A vote for the amateur relay operator
by torix＠protonmail.com 13 Sep '18

13 Sep '18

My vision for the tor project (toropia, if you will) is that running a relay be normal, i.e. part of the ritual of children leaving home for college would be to make sure their parents know how to reboot the tor relay in the basement when the power goes out. But it would be a big plunge for an amateur to set up an exit relay. So when Conrad Rockenhaus offered SWIPEd freeBSD installed relays, it seemed like a chance to get my feet wet. I have no freeBSD experience, but the new torproject directions turned out fine. I'm trusting that Conrad's install will be fine while I learn about hardened freeBSD and get plugged in about security updates. So Conrad gets the grief, and I just run the relay. Maybe I'm not a "real" relay operator for this one, but I think that's okay; I'm contributing to OS diversity, and a new exit relay. When Conrad wrote about getting a court order this week, and got a reply from teor, and said he was getting help with it, my reaction was "as least he seems to be getting help" - a comforting thought for an amateur reading this list who has never seen a court order. --torix Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 2

Exit node seized
by tor-relays＠geek1.de 12 Sep '18

12 Sep '18

Hello, I've found no information - after short googling - if I should take some action after an exit node got seized. Like marking the fingerprint as compromised or something like that. I'd guess it's ok to just set up a new exit node on the same IP and everything should be fine but I'm not quite 100% sure on this. Node in question: https://metrics.torproject.org/rs.html#details/AF8A3EE078EB81338461F178DBE5… And another question about this topic: Would it be better to create a new exit from scratch or is it ok to restore the latest backup with all keys, etc. ? Cheers Michael

4 6

Court Order
by Conrad Rockenhaus 10 Sep '18

10 Sep '18

Greypony received its first Court Order yesterday. Unfortunately, we have no records to provide since it was a Tor Exit, and we don’t even have records of who owned that relay at that IP address because we don’t keep records of the info. Oops. It’s a pretty broad Court Order, and kind of funny. Oh well. Conrad

6 9

Contact info on exit notice page?
by Isaac Grover, Aileron I.T. 10 Sep '18

10 Sep '18

Good morning fellow exit node operators, I am considering adding a dedicated email address (not this one) to be used for my exit nodes on the exit notice pages, where currently none exist. After reading this list for over two years and the stories of DMCA notices, court orders, etc., would an email address on the page provide some benefit to those parties who need to send complaints and piracy violations, or would it only attract more spam? Make your day great, Isaac Grover, Senior I.T. Consultant Aileron I.T. - "Practical & Proactive I.T. Solutions" Office: 715-377-0440, Fax:715-690-1029, Web: www.aileronit.com

2 1

Difference Between "Number of Routers" And "Number Of Descriptors"
by Keifer Bly 10 Sep '18

10 Sep '18

Hi, So upon checking my relay status at torstatus.blutimage.de, I saw Number of Routers In Cache: Number of Descriptors In Cache: I wanted to double check, what is the difference between “Number of Routers” and “Number of Descriptors”? I know Number of Routers means number of relays currently running. Thank you.

2 1

Reminder: Meeting in #tor-relays
by Colin Childs 09 Sep '18

09 Sep '18

Hi everyone, As promised, this is a reminder email that we will be holding our first IRC relay operator meeting this week! When: September 11th @ 1:00AM UTC Where: irc.oftc.net <http://irc.oftc.net/> @ #tor-relays You can confirm your local date / time by visiting the following page, and selecting your timezone from the dropdown menu: https://www.worldtimeserver.com/convert_time_in_UTC.aspx?y=2018&mo=9&d=11&h… <https://www.worldtimeserver.com/convert_time_in_UTC.aspx?y=2018&mo=9&d=11&h…> See everyone there!

1 0

Suspension of service (ISP Scaleway / tor exit)
by Olaf Grimm 08 Sep '18

08 Sep '18

Dear readers, some days ago I change my relay to an exit relay with a very strict policy. Today came the suspension message into my regular mail account. After login into the Scaleway account I saw that the time between the abuse log message and the deactivation of my exit relay were 6 hours only. At these time I was at work! I was not able to react of the message, neither I knew it. The "abuse message" was a raw firewall log, without spaces hard to read. I'm not a professional, so I could read only "SYNFLOOD src IP xxxx dest IP xxxx". That's all. After I learnt what this is, I responded to the provider that good providers realize own DDOS protection in the network and protect customers too. Why log the provider bad outgoing traffic and ignore bad incoming traffic? They don't know the source of the bad traffic, but have the customer to beat someone! The answer field for the reply were some lines only. Without comment from the ISP the ticket was closed and the VPS locked yet. I try to delete the old instance and build a new one. If the same occur I leave Scaleway (and give info about that again). Now I recommend to set the ISP Scaleway (in France) of the list of bad providers. Scaleway message: Hello, We have tried to contact you about an abuse report concerning one of your server. Unfortunately at this time you did not reply to this report. As stated in our terms of service, we have suspended your account. Sincerly, Scaleway End message To avoid a big shitstorm: I know what I do and it is not my first and only exit. Scaleway was the first trouble and in such a way, that I must leave a comment. To the tor website editors: It is possible to include a basic abuse protection chapter in the tor documentation (config guide)? I've found some iptable rules, but I use the user-friedly "ufw", the overlay to iptables. It would be fine if some good guys could help with an easy configuration guide in the config chapter for tor relays. Have a good time. I feel me better. Olaf

5 6

Lets increase Routing Security for Tor related BGP Prefixes
by nusenu 06 Sep '18

06 Sep '18

Hi, I measured the adoption of RPKI ROAs that help with routing security and some other properties for the >3k BGP prefixes that make up the Tor network. https://medium.com/@nusenu/how-vulnerable-is-the-tor-network-to-bgp-hijacki… You might want to jup directly to section "Recommendations for Tor Relay Operators". (I could paste it here but then all the URLs would be lost) Since OVH SAS and DO do not deploy ROAs at all yet: If you are an OVH SAS or Digital Ocean customer (directly or indirectly just on the same AS) it would be great if you could ask your customer support when they are planing to deploy RPKI ROAs (like other big hosters already did). thanks, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

3 8

4 of Conrad Rockenhaus trial servers are in the top ten exit relays for Canada
by zimmer linux 06 Sep '18

06 Sep '18

Hi, Just to let you know that following on with the one month trial with tor exit relays that Conrad kindly offered, at least four of his exit relays are now in the top 10 listing for Canada, out of 68 Canadian exit relays. https://metrics.torproject.org/rs.html#search/country:ca%20flag:exit Well done to Conrad - I say. The more, the merrier. If you want any help with setting up your own FreeBSD tor exit relay, feel free to contact me off list. Zim

13 31

Possible problem with NYX
by arisbe 05 Sep '18

05 Sep '18

Hello ops, Today I noticed something on NYX that I find disturbing. Page 2 (list of inbound/outbound connections) showed me the IP address of an inbound connection on one of my bridges! Not the authority. This is crazy as these are indicated as <scrubbed>:port for the users protection! I have never seen this before and haven't seen it since. Of course, on low usage bridges, the connection IP address can possibly be disseminated from netstat but that's not the point. It's my sense that this should never happen. I get chills imagining this happening on a guard relay operated by an antagonist ! ! I'm using the default NYX configuration on Ubuntu server 18.04.1 LTS, Tor 0.3.3.9. Arisbe -- One person's moral compass is another person's face in the dirt.

4 5

new exit relay 4AEBDC4710D2C34FE02AB2A660B62B2A9EE97C5C
by deep.thought＠riseup.net 05 Sep '18

05 Sep '18

Dear fellow relay operators, we are a loose collective of students inside AS553 (Universität Stuttgart) running one node there. At the moment, we are not allowed to run any nodes since two abuse complaints attracted too much attention to the NOC. The complaints were probably triggered by the well-known DDOS problems a few months ago. After all, the cloud operator was not amused at all but we are in the process of getting back our right to run middle relays in AS553 to support AS diversity. However, we are happy to announce a new exit node: 4AEBDC4710D2C34FE02AB2A660B62B2A9EE97C5C (howdoyouturnthison) in AS24940 (Hetzner) running on FreeBSD with a local DNS cache. We are aware of the fact that this is not supporting AS diversity but still better than no relay :) So far and thanks for all the fish, Random Person

4 4

FW: Re: [AusNOG] Dutton decryption bill
by I 05 Sep '18

05 Sep '18

1 0

Re: [tor-relays] Congrats to Nullvoid
by Paul 05 Sep '18

05 Sep '18

For me running several FreeBSD relays this is a great hint! Maybe it will find its way to https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD > Not a problem with FreeBSD. > > Switch over to https and latest... > > /etc/pkg/FreeBSD.conf: > > url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest", > > and run 'pkg upgrade' . > Could you please explain a bit more on this - what exactly to do ? > If it's a shared box, you probably also want > devcpu-data, and optionally cpupdate.

3 5

The Assistance and Access Bill 2018
by Paul Templeton 04 Sep '18

04 Sep '18

On a satire note - https://www.youtube.com/watch?v=eW-OMR-iWOE But seriously - https://www.homeaffairs.gov.au/about/consultations/assistance-and-access-bi… And - https://www.homeaffairs.gov.au/about/national-security/five-country-ministe… The thing that worries me is that this bill will probably go through and it can hoover up relay operators. That is they can force you to add/develop tools to eavesdrop on you. Is there any real defense against this bill? IE having a parameter in the torrc that would act like a canary? Paul 137CF322859E400455E457DB920F65FFDD222CDF

7 8

SSH login attempts
by Marcus Wahle 04 Sep '18

04 Sep '18

Dear all, Since 14:00 my logs (middle node) are spamed with around 100 faild ssh login attemps from different ips. Is there anybody else affected? Best regards Marcus

14 14

Multi node management programs/platforms?
by Isaac Grover, Aileron I.T. 04 Sep '18

04 Sep '18

Good evening, For those of you who manage multiple exits and/or relays, what program/platform do you use to manage them? Make your day great, Isaac Grover, Senior I.T. Consultant Aileron I.T. - "Practical & Proactive I.T. Solutions" Office: 715-377-0440, Fax:715-690-1029, Web: www.aileronit.com

9 11

9 routing security recommendations for relay operators
by nusenu 04 Sep '18

04 Sep '18

(mostly a copy paste from [0]) 1. Monitor your relay’s BGP prefix for suspicious BGP activity and share alerts with this mailing list. The easiest way to do so is to subscribe to your prefixes using https://bgpmon.net/. You should practically get zero alerts. 2. Check the following properties of the prefixes you use (ideally even before ordering servers): prefix length and IRR state [1] RPKI state [2] 3. Ask your ISP/IP holder to create ROAs [4] for the prefixes you use, if the ROA is currently missing. 4. Ensure the ROA creator is aware of the risks of the maxlength attribute [3] and uses it accordingly (in the best case not at all) 5. Monitor the RPKI validity state of your prefixes (can also be done with bgpmon) 6. Ask your ISP to announce the IP space of your relays in /24 prefixes (/48 for IPv6) to avoid more-specific prefix hijacks (this makes sense even if you have ROAs in place due to the low ROV coverage) 7. If your relay uses IP addresses from the RIPE region: ask your provider to create route(6) objects matching the announcements if they are not present yet. You can use RIPEstat’s prefix routing consistency widget [1] to check the current state (the “In RIS” and “RIPE IRR” columns should both say “yes”). 8. Be aware that “LEGACY” or “ERX” IP space might be less likely to get ROAs by your ISP 9. Enable IPv6 on your relays [0] https://medium.com/@nusenu/how-vulnerable-is-the-tor-network-to-bgp-hijacki… [1] https://stat.ripe.net/widget/prefix-routing-consistency [2] https://rpki-validator.ripe.net/bgp-preview [3] https://www.youtube.com/watch?v=I3Owb0u8Wuk [4] https://www.ripe.net/manage-ips-and-asns/resource-management/certification/… https://www.arin.net/resources/rpki/using_rpki.html -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 0

relayor v18.1.0 is released
by nusenu 04 Sep '18

04 Sep '18

Hi, relayor v18.1.0 is released. relayor helps you with running relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor Changes since v18.0.0: ------------------------------ - enable NoExec by default on all platforms except CentOS - increase min. ansible version from 2.5.3 to v2.6.2 - fix the ExitPolicy format in the example playbook - change default shipped exit policy (remove POP3, IMAP and kerberos ports) - change the ControlSocket location -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 0

Unmeasured - 69D9FF1BE14B9AE77701A6BCBC075FF837F5AFF9
by Dark Matter 03 Sep '18

03 Sep '18

Greetings, my relay 69D9FF1BE14B9AE77701A6BCBC075FF837F5AFF9 (darkmatter) recently (3 days) received an Unmeasured flag and is considered to be offline. I could not detect any issues on my side and wondered if you could help me to resolve this. Best regards, Dark

2 1

Relay operators meetup part #2 @ Onionspace, Berlin
by Vasilis 03 Sep '18

03 Sep '18

Dear Tor friends and relay operators, Next Saturday (25/08/18) a follow-up relay operators meetup will take place at Onionspace, Berlin. The meetup will start at 16:00 and depending on the weather we may move afterwards to the garden. When: Saturday, August 25th, 2018 Start Time: 16:00 / 4:00 PM Where: Gottschedstrasse 4, Entrance 4, 13357 Berlin (U Nauener Platz), Onionspace Map: https://www.openstreetmap.org/#map=18/52.54978/13.36991 Event link: https://blog.torproject.org/events/tor-friends-and-relay-operators-meetup-2… Hope to see many of you there. Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162

1 1

Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship
by grarpamp 02 Sep '18

02 Sep '18

This particular case receiving mentions for at least a few months... D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114 The relay won't [likely] be badexited because neither it nor its upstream is shown to be doing anything malicious. Simple censorship isn't enough. And except for such limited censorship, the nodes are otherwise fully useful, and provide a valuable presence inside such regions / networks. Users, in such censoring regimes, that have sucessfully connected to tor, already have free choice of whatever exits they wish, therefore such censorship is moot for them. For everyone else, and them, workarounds exist such as,,, https://onion.torproject.org/ http://yz7lpwfhhzcdyc5y.onion/ search engines, sigs, vpns, mirrors, etc Further, whatever gets added to static exitpolicy's might move out from underneath them or the censor, the censor may quit, or the exit may fail to maintain the exitpolicy's. None of which are true representation of the net, and are effectively censorship as result of operator action even though unintentional / delayed. Currently many regimes do limited censorship like this, so you'd lose all those exits too for no good reason, see... https://ooni.torproject.org/ https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_count… And arbitrarily hamper spirits, tactics, and success of volunteer resistance communities and operators in, and fighting, such regimes around the world. And if the net goes chaotic, majority of exits will have limited visibility, for which exitpolicy / badexit are hardly manageable solutions either, and would end up footshooting out many partly useful yet needed exits as well. If this situation bothers users, they can use... SIGNAL NEWNYM, New Identity, or ExcludeExitNodes. They can also create, maintain and publish lists of whatever such classes of nodes they wish to determine, including various levels of trust, contactability, verification, ouija, etc... such that others can subscribe to them and Exclude at will. They can further publish patches to make tor automatically read such lists, including some modes that might narrowly exclude and route stream requests around just those lists of censored destination:exit pairings. Ref also... https://metrics.torproject.org/rs.html#search/as:AS197328%20flag:exit https://metrics.torproject.org/rs.html#search/country:tr%20flag:exit In the subect situations, you'd want to show that it is in fact the exit itself, not its upstream, that is doing the censorship. Or that if fault can't be determined to the upstream or exit, what would be the plausible malicious benefit for an exit / upstream to block a given destination such that a badexit is warranted... a) Frustrate and divert off 0.001% of Turk users smart enough to use tor, chancing through tor client random exit selection of your blocking exit, off to one of the workarounds that you're equally unlikely to control and have ranked, through your exit vs one of the others tor has open? b) Prop up weird or otherwise secretly bad nodes on the net, like the hundreds of other ones out there, for which no badexit or diverse subscription services yet exist to qualify them? c) ??? Or that some large number of topsites were censored via singular or small numbers of exits / upstreams so as to be exceedingly annoying to the network users as a whole, where no other environment of such / chaotic widespread annoyance is known to exist at the same time.

12 25

Policy Question: Tor Exits at Universities, Corporate Networks, etc
by Nathaniel Suchy 02 Sep '18

02 Sep '18

Recently we've been discussing a Tor Exit in Turkey censoring access to various websites. It's less to some err, disagreements on what should and should not be allowed. I've seen a few opinions: *) It grants an outside view at what Turkey censors *) It could push new tor users away This leads me to question if it's okay for a Tor Exit to be on a censored network are the following scenarios now allowed? *) A Tor Exit behind a Corporate Network and Web Filter *) A Tor Exit behind a University Network and Web Filter Under the logic with the Turkey exit relay it should be right? Cordially, Nathaniel

5 5

Message to devs, please don't change log strings
by gustavo 02 Sep '18

02 Sep '18

Hi In the last few months I started to monitor more closely my relays parsing their logs, but every new update changes the log strings. Can the devs be mindful to relay ops and not change strings needlessly? Here is an example 0.3.3.9 Sep 1 00:01:32 serverhostname tor[15341]: Sep 01 00:01:32.042 [notice] 0.3.something Sep 1 00:01:32 serverhostname Tor[15341]: Sep 01 00:01:32.042 [notice] 0.2.9 Sep 1 00:01:32 serverhostname Tor[15341]: [notice] I'm logging to syslog thanks! -- IRC: gfa GPG: 0X44BB1BA79F6C6333

3 3

Tor Meetup Hamburg, August 31st
by Alexander Dietrich 01 Sep '18

01 Sep '18

Hi everyone, we would like to invite people interested in the Tor project and relay operators in the Hamburg area to meet at the CCC Hamburg. There will be an introduction to Tor, a Q&A session and a brief announcement about a future Hamburg-based Tor association. We would love for relay operators to meet and discuss ways of strengthening the network. When: Friday, August 31st, 6:00 PM Where: CCC Hamburg, Zeiseweg 9 ( https://hamburg.ccc.de/#wegbeschreibung ) WWW: https://hamburg.ccc.de/2018/08/20/tor-meet-up-beim-ccchh-index/ Be seeing you, Alexander -- PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB

3 3

Abuse Complaints
by Paul Templeton 30 Aug '18

30 Aug '18

Question: are exit operators seeing many abuse complaints now days? I have only had one in the last two months from 5 exits. I used to see a lot now nothing really. I just find it weird. Paul 137CF322859E400455E457DB920F65FFDD222CDF

9 14

log "Is your outbound address the same as your relay address?"
by Tim Kuijsten 30 Aug '18

30 Aug '18

Hi, I just setup a new relay[0]. One of the messages I got is the following: "Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 12 connections to 8 relays. Found 12 current canonical connections, in 0 of which we were a non-canonical peer. 4 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections." When I had setup another relay last week[1] I got the same message, and it didn't reappear so I assume this is about starting up a new relay and is nothing to worry about. I just thought I'd let you know. The hostnames of both machines matches the public dns and reverse dns names. Furthermore each machine has only one public ipv4 address, which is also set in it's local /etc/hosts file. At one machine I had set "Address" in the torrc as well, but this didn't avoid getting this message once. Kind regards, Tim [0] tosk B183A69592D2E8C8C487C054D0849E3C9561DC11 [1] kali 2C76951164C5184A3B8B7CC1914B34E4622B225F

2 1

Test bed in MyFamily?
by Totor be 30 Aug '18

30 Aug '18

Hi list, Just a quick question about families: I'm in the process of setting up a 4th relay as test bed VM in order to validate the Linux and Tor updates before updating my 3 live relays (none of these are exits) This 4th relay will be fully operational, but will only be started from time to time, when updates are available After the updates are installed, I plan to leave it running for half a day or so until it appears in Tor Metrics Question: should I include this test bed relay in MyFamily or leave it completely stand alone? What would you recommend? Thanks! Patrick

4 4

Limiting open port RST response from N to M packets/sec (FreeBSD)
by nusenu 30 Aug '18

30 Aug '18

Hi, I'm curious as to how frequent FreeBSD relay operators that do not make use of any packet filter get something like the following line in their logs: kernel: Limiting **open** port RST response from ... to 200 packets/sec -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 1

Cloudflare Onions Beta and Network Stability
by Nathaniel Suchy 29 Aug '18

29 Aug '18

As some of you may have heard, Cloudflare is beta testing opportunistic onions. This of course is going to create more Tor traffic. Cloudflare has several concerns about running their own relays and says they won’t at this time. That said if every Cloudflare website becomes an Onion Service overnight how would that affect network stability and what can we as relay operators do to prepare for it?

11 17

The truth about Greypony
by Tor Professional 29 Aug '18

29 Aug '18

The truth must come out eventually about the menace known as Greypony. Now that people are beginning to realize what a menace to our network Greypony really is maybe this information will finally get us to banish him once and for all. Greypony has no real customers. You will not find a legitimate customer because they do not exist. They are all one Conrad Rockenhaus. Just so you know. Do you know any of the people that are bragging about using Greypony? Are they true professionals that use Tor? I do not think so. Find one person that you can legitimately trust that has used Greypony or that has dealt with Rockenhaus legitimately and you will not find one because such a person does not exist. Greypony lies about their bandwidth numbers. Those numbers are impossible. How are they eclipsing some of the fastest tor exits on the Internet? How are they operating the fastest exits in Canada? By lying about their numbers and cheating. What are Rockenhaus' motives for doing this? He says he wants to help Tor but we all know that he is full of it. Why would someone like him want to help us? We do not need someone like him. We can do better. We are better. Let us apply a little chemotherapy to the cancer and kill off Greypony.

3 4

Re: [tor-relays] Individual Operator Exit Probability Threshold
by Paul Templeton 28 Aug '18

28 Aug '18

> About finding sponsors for high speed exits, it could be nice > to gather ideas. Can I ask what is a high speed/capacity exit? For me it would be >10MiB/s am I correct? Paul

4 6

[release] ExoneraTor 3.0.1
by Karsten Loesing 28 Aug '18

28 Aug '18

Hi relay operators, today we released ExoneraTor 3.0.1 which fixes links to IP addresses in the same /24 or /48 IP network (#27266). This is also the first release after making several code improvements, which ideally should not affect operation. But just in case something breaks that was previously working, this could be the reason. Please direct any comments or questions to the (public) metrics-team mailing list: https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team All the best, Karsten

1 0

Protecting Tor Circuit path selection from correlation attacks by an autonomous system
by Nathaniel Suchy 28 Aug '18

28 Aug '18

This thread continues the broader discussion of Tor Circuit path selection discussed at https://lists.torproject.org/pipermail/tor-relays/2018-August/015994.html regarding possible correlation attacks by an autonomous system. *Current measures include:* * Preventing two relays from the same /16 in IPv4 and /32 in IPv6 networks, from being in the same Tor circuit. CIDR is helpful, but is it enough? * The MyFamily directive, this does rely on relay operators being honest and we shouldn't rely on this as the sole indicator. * Others things that I am not aware of? *Some measures worth considering include:* * Preventing two relays in the same ASN from being in a circuit. * Maybe prevent two relays in the same ASN from being Guard and Exit, excluding the middle relay from this calculation. * Bridges could be a challenge when implementing this, although it's not impossible. * Looking at relays with same/similar names, heuristics maybe? It's really guesswork but hey it might work. * Looking at relays with same/similar contact info * Looking at relays in the same geographic regions and avoiding them * Relays with the same non-standard ports - excluding 9001, 9030, 80, 443 (anything else that's super common?) * On device models looking at the above data to make decisions of which relays are most likely run by the same entity, use machine learning to make an informed decision based on all factors maybe? *Papers worth reviewing:* * AS-awareness in Tor Path Selection https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf * Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries https://www.ohmygodel.com/publications/usersrouted-ccs13.pdf * Moving Tor Circuits Towards Multiple-Path: Anonymity and Performance Considerations https://pdfs.semanticscholar.org/aa94/7dd4762bd0f6531bacfeac9d29ef1e1d4cd6.… * Avoiding The Man on the Wire: Improving Tor’s Security with Trust-Aware Path Selection https://www.nrl.navy.mil/itd/chacs/sites/www.nrl.navy.mil.itd.chacs/files/p… *Outside the scope:* * In AS-es where Virtual Machines are sold, and Physical Machines are not. It's quite possible that the provider may steal relay keys. Little research exists where you could successfully protect against such an adversary who isn't playing nice. Legislation (For example, GDPR) in the EU exists where such activity may violate local laws. This may or may not be enough. Certainly not against a government actor, but against an AS doing it per their only devices maybe. * An AS hosting a Tor relay who logs or watches network traffic will always be able to learn something about the circuit, but perhaps we can prevent them from learning everything about the circuit most of the time. Everyone on the list has a had very insightful and helpful thoughts on this discussion so far and I'm looking forward to getting more discussion of the broader issue. Cordially, Nathaniel Suchy

2 1

Avoiding Off-Topic Posts
by teor 27 Aug '18

27 Aug '18

Hi, A healthy, robust, and growing tor network needs a lot of different ways to run tor relays. Focusing on one or two models creates single points of failure. So we encourage individual volunteers, organisations, donations, paid services, and researchers: as long as they operate ethically and prioritise user safety. That said, this list is for "support and questions about running Tor relays". In future, please: * keep on topic, we are here to help each other run Tor relays * make sure each post contains new, useful information. You can search the archives before posting: https://lists.torproject.org/pipermail/tor-relays/ * avoid promoting or criticising the same providers more than once a month * deal with commercial / payment issues off-list But you should feel free to ask questions about operating relays at any time. T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ----------------------------------------------------------------------

1 0

Issues regarding 185.125.33.114 relay
by Nathaniel Suchy 27 Aug '18

27 Aug '18

Can the operator of the relay 185.125.33.114 please reach out to me? There is not any contact information available on Tor Metrics for the relay. Cordially, Nathaniel Suchy

3 2

Congrats to Nullvoid
by Conrad Rockenhaus 27 Aug '18

27 Aug '18

I just wanted to say congratulations to Nullvoid, who is currently running the second fastest exit in France in my colo in Europe. https://metrics.torproject.org/rs.html#details/51420DFB2047A33803A9A6E456D6… Also, go FreeBSD! Thanks, Conrad

4 5

Re: [tor-relays] Individual Operator Exit Probability Threshold
by livak 25 Aug '18

25 Aug '18

Hi ! In a an older thread I read: > Like Teor mentioned, it's important for operators to increase capacity > and stability, while still meaningfully supporting diversity. Emerald > Onion is not going to surpass 10% of exit capacity without first > helping ~10 other groups set up and manage their own 1%+ relays. As > more and more high-capacity groups come online, I think orgs like > Quintex and Emerald Onion can slowly increase capacity but stick > around the 10% line. Is there any help for setting up new high capacity exit relays ? Livak Sent with [ProtonMail](https://protonmail.com) Secure Email.

4 6

Yay, Complaints
by Conrad Rockenhaus 25 Aug '18

25 Aug '18

So, new equipment gets plugged into a colo…. I’m a dude that was looking to increase AS diversity on Tor and well, decided to add a new colo to the mix. Two exit relays are brought online on properly SWIPed IP addresses. These exit relays have only been online for about 24 hours. An organization, known as Irdeto Intelligence, ignores the fact that the IP addresses are SWIPed and sends abuse complaints to my upstream providers asking them to straighten me out, because I’m a pox on society because people are torrenting via Tor. They have sent over 40 emails in the last 12 hours. Some dude-man, who calls himself a “Network Security Administrator” who asked me to explain what Tor is……….because he’s a Network Security Administrator……..has told me that due to the volume of complaints I need to block the offending applications from their network. I told him that I spoke with them prior to bringing this stuff online, explained what Tor was, explained what a Tor exit was, explained that it will generate complaints, explained the DCMA liability, explained the whole thing…..and was told that they were okay with it. I’m sorry for the bitching and moaning…it’s just another case of doing everything right and now I’m quite worried that they’ll not only pull the plug, that I’ll have to fight to get my Cisco UCS blade server back (and other assorted equipment) which is totally not going to be cool. Conrad

6 9

Freebsd trial with greypony.it was a success
by zimmer linux 24 Aug '18

24 Aug '18

Hi, Conrad Rockenhaus - with your guidance and support with freebsd, within just 21 days total running time, you have helped me set up and manage the fastest exit relay in all of Canada. See https://metrics.torproject.org/rs.html#search/country:ca%20flag:exit https://metrics.torproject.org/rs.html#details/D9B1E08CC91F7F42EEE5578EA8B0… Give yourself a pat on the back. If anyone wants to talk through running a freebsd relay, feel free to contact me off list. Zim

1 0

Snowflake PT
by Nathaniel Suchy 24 Aug '18

24 Aug '18

Hi everyone, Tor Browser 8 Alpha includes the Snowflake PT as it comes near a final release, the adoption and usage of the Snowflake PT will continue to rise. I now have the following questions... 1) Will a command line tool like an obfs4proxy come out so those of us with infrastructure can run high capacity snowflake bridges. 2) Is the goal to replace OBFS4 with Snowflake or will they continue to co-exist? 3) How does Snowflake attempt to obfuscate, if at all it's traffic? How strong is the cryptography compared to obfs4proxy Looking forward to learning more about this :) Cordially, Nathaniel Suchy

3 7

Dropping packets with TCP MSS=1400 to foil GFW active probing
by David Fifield 21 Aug '18

21 Aug '18

A paper from FOCI 2018 by Arun Dunna, Ciarán O'Brien, and Phillipa Gill on the subject of Tor bridge blocking in China has this interesting suggestion (Section 5.2): https://www.usenix.org/conference/foci18/presentation/dunna To do this, we write a series specific rules using iptables in order to drop packets from Chinese scanners. ... We use a rule to drop incoming Tor packets with an MSS of 1400. Further investigation would be needed to analyze potential false positives... We note that this method of dropping scan traffic successfully keeps our bridge relays from being blocked and allows our client in China to maintain access to the bridge. Like https://github.com/NullHypothesis/brdgrd, surely this trick won't work forever, but if you're setting up a new bridge, it's worth a try? This is completely untested, but I think the iptables rule would look something like this: iptables -A INPUT --protocol tcp --dport [your-bridge-port] -m tcpmss --mss 1400 -j DROP Then, after a while, check /var/lib/tor/stats/bridge-stats and see if you have any connections from "cn".

3 6

Interested in running a FreeBSD Relay on Cogent?
by Conrad Rockenhaus 21 Aug '18

21 Aug '18

Would you like to trial a FreeBSD Relay on Cogent until October 1st? Yes, it has to be FreeBSD, because I use Bhyve as my hypervisor and some of my blades don’t support UG, which means, I support FreeBSD only on these series of servers. If you’re interested in a Model “A” (25GB HDD, 1vCPU, 2GB RAM, burstable up to 1gbit of bandwidth/unlimited transfer) running FreeBSD and would like to try it out until October 1st, just send me your Public Key. My hope is you will keep it online and hopefully increase the BSD Relay percentage to 7%. After October 1st its only $15/mo, which is my costs alone. You don’t have to worry about abuse complaints, I handle that for you. You just worry about running your exit and maintaining your OS. I take care of everything else. If you’re interested, send me a public key. Thanks, Conrad

1 0

contact for relay in AS64484
by nusenu 20 Aug '18

20 Aug '18

please drop me an email if you are the operator of F0AA2DB7B4B2E7927F88286788773844B68E2C01 Unnamed at 191.96.249.110 thanks! -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 0