tor-relays June 2019

tor-relays@lists.torproject.org

43 participants
35 discussions

Questions to ask exit node providers
by F67 Group 08 Oct '19

08 Oct '19

We are thinking of running a Tor Exit Node. Does anybody have a list of questions to ask before purchasing a VPS or colocation? I came up with some basic questions: - Do you allow a Tor exit node? [with explanation] - What are the policies for handling abuse complaints? - How much uplink bandwidth do you provide? Any other questions one should ask? Thanks.

17 49

Emerald Onion's new relays
by Christopher Sheats 20 Aug '19

20 Aug '19

Hello, Beginning this Wednesday, 2019-Apr-03, Emerald Onion will be starting 40 new uncapped and unfiltered exit relays using HardenedBSD in Seattle. We will turn on 10 new relays per day and be monitoring performance. In tandem, we will be publishing our updated edge routing and Tor relay configurations on our Github. We'll also publish an updated transparency report (spoiler: zero new requests). This work is part of our efforts to saturate our new unmetered 10Gbps transit link in the Westin data center. There we peer with the Seattle Internet Exchange with a separate 10Gbps connection. We'll be using our existing IP scopes: 2620:18C::/36 23.129.64.0/24 We are in the process of creating an RPKI ROA for our prefixes, and we are still rebuilding our DNS resolver (thanks nusenu for the feedback). These things will be completed before we turn on the new relays. If you donated to Emerald Onion (a 501(c)(3)) nonprofit), thank you! We'll be naming the relays accordingly. We will still accept new donations for relay naming rights-- email me directly for more information. Lastly, and If you're unaware, I spoke about our work at DEFCON 26: https://www.youtube.com/watch?v=cs6a1i4Owic Cheers, -- Christopher Sheats Executive Director for Emerald Onion Email: yawnbox(a)emeraldonion.org Office (& Signal): +1-206-739-3390 Website: https://emeraldonion.org/

12 20

10 Years Torservers.net: Death or Future?
by Moritz Bartl 08 Aug '19

08 Aug '19

tl;dr: torservers.net needs a new home! I started torservers.net after a random chat at a local bar some time early 2010. I wore a Tor shirt, and the guy next to me asked if that was "The Onion", the satire magazine. He became pretty excited about Tor after I told him what it was about, opened his wallet and gave me a 100€ bill "to put towards the network". Eventually it turned out that he was an Oracle software developer, so it's kind of funny to think about this as "one of the few good things Oracle has ever done". I thought about it for a bit, and then decided to take the money, which cemented the idea that I have had for quite some time: to get a more beefy machine to "properly" run a Tor exit, sharing the costs with others. Only a few days after I announced this idea on or-talk [1] in May 2010, some crazy Swede wired me another 1000€ (Thanks!). So, bad luck, I really had to do this now! I am still surprised at how successful the fundraising was. In fact, when we finally created a legal envelope of protection around me by starting the Zwiebelfreunde association in 2011, it was already clear that we needed to find others to do the same, instead of growing larger ourselves. The network was a lot different then, and some people tell me we had 80% of the overall exit capacity for quite some time after Olaf shut down his fast Blutmagie exit. So I went on a tour to inspire others. So, here we are, almost 10 years later, with 23 partner organizations in 15 countries. [2] After I got a "real job" in 2013 (that quickly grew into "more than full-time"), and at the same time the first grant money for torservers.net, we tried in many different ways to "recruit" others to "take over". Looking back, of course a lot of things happened and it was a crazy (and fun!) time, but long story short, until now nobody stepped up to take over the core role of a "coordinator" of activities. There are many many offers for help, and even more ideas of what torservers.net could do and be, but all people involved heavily at the beginning (Thanks!) don't have time to coordinate all the wonderful help, and do a proper handover. We tried a couple of times, only to spend a lot of time "training" a poor person to get them somewhat up to speed, but eventually everyone decided they had better things to do than to become frustrated at trying to walk blindly without much guidance. This is not an easy role to step into. If we take the May 2010 announcement as "launch date", the 10 years anniversary will be on May 10th, 2020. My dream would be to celebrate this with a fresh board at Zwiebelfreunde that has taken over the association, and another group that coordinates the international platform that torservers.net was meant to be(come). Of course we will not simply give away the domains and the legal entity and all our exit relays to just anyone. But, hm, yeah, truth is, probably almost anyone! ;-) For some years now, we've talked about the idea of a "relaunch". The most promising idea is to organize a proper Tor Relay Operators Retreat, maybe 50 people or so, with all the great people who have dedicated their lives to this project at some point, and all the great new folks who are as excited as all of us were back then about contributing to the Tor network. It would likely to be possible to convince Open Technology Fund or some other money source to sponsor travel and venue. I've always imagined this to happen in a nice "holiday" setting. At some point, I *will* go with a group of people to this fine venue [3], as an example of how this could look like. So far, I've tried to talk to individuals about it in smaller groups, and never announced it to the broader community in the way I do now. However, I still believe that this can only really be moved forward _in person_. I will do my best to ignore all mails you write to me or in this thread. Please write, coordinate, do everything that you think would be good to do to move this forward, but I don't really have the capacity to lead a good discussion. The only capacity I can offer is that we *need* someone to step up, and grab me at some event in meatspace. Ideally at that point that person is willing to have the A record pointed at some new place under their control, and we can begin the transition. Otherwise we will probably simply kill it for the 10 years anniversary, and finally make room for something new altogether. This is a call for help! Thanks. :-) Moritz P.S.: I will at some point soon post another mail about what I was up to the past years, and what I will be up to in the next few years. Don't worry, I'll still be around. [1] http://archives.seul.org/or/talk/May-2010/msg00058.html [2] https://torservers.net/partners.html [3] For a real Tor Relay Retreat, we would need something larger, but I think this gives you a pretty good idea of how I imagine it to look like: https://www.homeaway.co.uk/p868562

10 20

exit operators: overall DNS failure rate above 5% - please check your DNS resolver
by nusenu 30 Jul '19

30 Jul '19

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. Exit relays which fail to resolve hostnames are barely useful for tor clients. We noticed that lately the failure rates did increase significantly due to some major exit operators apparently having DNS issues and we 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_ https://mastodon.social/@nusenu

11 15

Call for setting up new obfs4 bridges
by Philipp Winter 19 Jul '19

19 Jul '19

Hi everyone, BridgeDB is running low on obfs4 bridges and often fails to provide users with three bridges per request. Besides, we recently fixed a BridgeDB issue that could get an obfs4 bridge blocked because of its vanilla bridge descriptor: <https://bugs.torproject.org/28655> We therefore want to encourage volunteers to set up new obfs4 bridges to help censored users. Over the last few weeks, we have been improving our obfs4 setup guide which walks you through the process: <https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4…> The guide provides instructions for Debian, Ubuntu, CentOS, RHEL, OpenSUSE, FreeBSD, and OpenBSD. If you're running into any issues with the guide, please let us know! Finally, once you set up an obfs4 bridge, make sure that both your ORPort *and* your obfs4 port are reachable. Tor currently only tests the reachability of its ORPort. We set up a service that allows you to test the reachability of your obfs4 port: <https://bridges.torproject.org/scan/> Thanks for keeping the Tor network healthy by running relays and bridges! Thanks, Philipp

9 15

obfs4 relay lost stable flag
by tor 01 Jul '19

01 Jul '19

Hi I've been running an obfs4 bridge for about a month. My hashed fingerprint is: E120A0492F789F5367EAD84C64F92EE279018F98 I recently lost the stable flag. Not sure why. Any thoughts? thanks matt

3 2

Tor Performance on Xen vs KVM
by Conrad Rockenhaus 30 Jun '19

30 Jun '19

Hello, I’m just curious on how people feel about relay performance on Tor nodes running on Xen vs KVM. I’ve noticed on Xen I have increased network performance and I do like the improved modular architecture of Xen vs KVM (right now I’m working on an experimental OpenStack w/ XCP-ng environment). I was wondering if any others on the list had experience running high performance Tor nodes on Xen and KVM and have a preference for one over the other… I’m just trying to compare and contrast here. Of course, I built a XCP-ng pool with a compute VM, then I have a regular KVM compute instance running under the Openstack framework. Thanks, Conrad Rockenhaus http://www.greyponyit.com/

1 0

BridgeDB currently up but non-functional?
by Rick Huebner 28 Jun '19

28 Jun '19

Hi, all. While skimming /r/tor on Reddit I saw a couple of posts saying they hadn't been able to get any usable bridges for several days, and thought I'd check into it. I downloaded & installed a fresh copy of the Windows TBB 8.5.1 and had it ask for bridges via Moat, and received 2 (not 3?) obfs4 bridge lines. Here's the Tor log from the "copy to clipboard" button that popped up on the TBB "connecting" dialog when it stalled at about 3/4th of the progress bar: 6/19/19, 10:46:16.735 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:46:16.735 [NOTICE] Switching to guard context "bridges" (was using "default") 6/19/19, 10:46:16.735 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:46:16.736 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:46:16.736 [NOTICE] Opening Socks listener on 127.0.0.1:9150 6/19/19, 10:46:16.736 [NOTICE] Opened Socks listener on 127.0.0.1:9150 6/19/19, 10:46:16.736 [NOTICE] Renaming old configuration file to "C:\Downloads\Tor Browser 8.5.1 - Copy\Browser\TorBrowser\Data\Tor\torrc.orig.1" 6/19/19, 10:46:23.608 [NOTICE] Bootstrapped 5%: Connecting to directory server 6/19/19, 10:46:23.611 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 6/19/19, 10:46:24.558 [NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection 6/19/19, 10:46:24.748 [NOTICE] Bootstrapped 20%: Asking for networkstatus consensus 6/19/19, 10:46:24.954 [NOTICE] new bridge descriptor 'eldritchworld' (fresh): $<BRIDGE 1 FINGERPRINT REDACTED>~eldritchworld at <BRIDGE 1 IP REDACTED> 6/19/19, 10:46:25.589 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:26.781 [NOTICE] Bootstrapped 25%: Loading networkstatus consensus 6/19/19, 10:46:28.291 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. 6/19/19, 10:46:28.482 [NOTICE] Bootstrapped 40%: Loading authority key certs 6/19/19, 10:46:28.997 [NOTICE] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services. 6/19/19, 10:46:28.997 [NOTICE] Bootstrapped 45%: Asking for relay descriptors for internal paths 6/19/19, 10:46:28.997 [NOTICE] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6440, and can only build 0% of likely paths. (We have 100% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.) 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.275 [NOTICE] Bootstrapped 50%: Loading relay descriptors for internal paths 6/19/19, 10:46:29.463 [NOTICE] The current consensus contains exit nodes. Tor can build exit and internal paths. 6/19/19, 10:46:29.463 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.463 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.463 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.514 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.514 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.672 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.672 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.672 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.283 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.283 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.283 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Bootstrapped 57%: Loading relay descriptors 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.684 [NOTICE] Bootstrapped 64%: Loading relay descriptors 6/19/19, 10:46:30.684 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.733 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.733 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.733 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.873 [NOTICE] Bootstrapped 73%: Loading relay descriptors 6/19/19, 10:46:30.873 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.873 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.881 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.881 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.881 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.937 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.969 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:44.618 [WARN] Proxy Client: unable to connect to <BRIDGE 2 IP REDACTED> ("general SOCKS server failure") It looks like bridge 1 (eldritchworld) gave me bad/incomplete relay info which prevented making circuits, and then Tor failed to connect to the fallback bridge 2 at all. Checking Relay Search, it shows that eldritchworld is a normal healthy-looking bridge that's been up for months with plenty of connections and data being transferred, so I don't know what's wrong there. So, since the Moat bridges didn't work, I went to the BridgeDB request web page to try that. Clicking the "Just give me bridges" button and doing the captcha returned "Uh oh, spaghettios! There currently aren't any bridges available... Perhaps you should try going back and choosing a different bridge type!". What, no vanilla bridges available at all? Seriously? (As a side note, cutesy errors are pretty annoying when things are failing. Just sayin'.) And as usual the Metrics page still shows about 1000 bridges, so something's badly broken. I know the new bridgedb release doesn't give out ORports if there's a secure PT offered, but last I checked the majority of bridges were just vanilla, so surely there must be enough to put some into whichever bridge pool ring my request was pulled from. I then tried asking for obfs4 bridges instead, and it did give me one (again, not 3?). With another fresh install of the TBB and entering that bridge line, the log shows: 6/19/19, 10:59:43.912 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:59:43.912 [NOTICE] Switching to guard context "bridges" (was using "default") 6/19/19, 10:59:43.912 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:59:43.912 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:59:43.912 [NOTICE] Opening Socks listener on 127.0.0.1:9150 6/19/19, 10:59:43.912 [NOTICE] Opened Socks listener on 127.0.0.1:9150 6/19/19, 10:59:43.912 [NOTICE] Renaming old configuration file to "C:\Downloads\Tor Browser 8.5.1 - Copy\Browser\TorBrowser\Data\Tor\torrc.orig.1" 6/19/19, 10:59:50.761 [NOTICE] Bootstrapped 5%: Connecting to directory server 6/19/19, 10:59:50.762 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 6/19/19, 11:00:11.767 [WARN] Proxy Client: unable to connect to <BRIDGE 3 IP> ("general SOCKS server failure") So this 3rd bridge also failed to connect at all. With the Moat and website requests both returning bad/dead bridges (if any), the last thing to try was the email request channel. I sent "request bridges" to bridges(a)torproject.org and it replied back "Here are your bridges: None, None, None". Well, okay then. Maybe if I try again later, which should give me different bridges to use? According to the bridgedb config file checked into the git repo, the rotation periods for the Moat and website bridge pool query positions are both 3 hours. So I waited 3.5 hours and tried those tests again on another fresh TBB install copy, and both Moat and the website returned back to me the exact same bridges as before, which then failed in the same ways as before. Maybe the running server isn't using the checked-in config settings? Waiting another 8 hours (11.5 total since the first try), Moat gave me the same first bridge but finally a different second bridge (still not 3), but that one also failed to connect at all with the same "general SOCKS server failure". The website still claims there are no vanilla bridges available at all, and gives me back the same single obfs4 choice as before, which still won't connect at all. I don't know if it's the link between the bridge authority and the bridgdb server, or the new bridgedb release that just came out or what, but something's badly broken and the bridgedb appears to be pretty much useless right now. My test environment is very standard, just Windows 10 Pro using only IPV4 from a normal US ISP (Frontier FIOS near Portland, OR) with no proxy, running a fresh copy of the current TBB build. The TBB works fine if I don't use a bridge or if I manually enter the bridge info for a private bridge relay I temporarily set up, and I have no other internet issues. Could someone else check if they see similar problems? Other people should supposedly get different bridgedb results pulled from the other bridge pool rings, but even if it's somehow only affecting one pool ring, that's like 20-25% of the bridgedb's users left with no viable results. Looking at the Metrics site I don't see any drop in current bridge user counts (actually it's in an uptrend, along with all tor user counts lately) but I'd assume most bridge users already have working bridge lines cached, so this would only affect new users or those whose old choices have gone down, but both of those categories will only grow with time.

2 5

An easy self-DoS and how to avoid it
by j4c4l4 28 Jun '19

28 Jun '19

Hi there, I have been operating a non-exit relay and a bridge for about one week now. I discovered by chance a quite silly self-DoS which could be triggered by using a NIDS (Network Intrusion Detection System) on relays. I don't know if it is known, but I thought it was worth reporting it here. In many Linux distributions, several NIDSs come with a default policy that blocks all the traffic from offending IPs after they have reached a threshold score. The offending IPs are normally put into a separate firewall chain/table that DROPs all the traffic originating from them, and then re-enabled after a period that could vary between 30 minutes and a few hours (again, depending on the config). Now, this could be potentially used to periodically shut down relays. In fact, an attacker could perform something as simple as an ssh login scan *through tor*, which is among the "attacks" monitored by most of the NIDS out there. But since the login attempts appear to originate from the tor exit relay, this effectively flags *the exit* as an "offending" host, and triggers the corresponding firewall rule (which is normally a blind "DROP", to save on rule processing). Once an exit node is flagged as "offending" and put in the firewall rule, any traffic between the relay and the exit node is effectively forbidden, until the firewall rule is removed or the tables flushed. If performed on a large scale, this can potentially shut down all the relays which run a NIDS with such policy on ssh logins. The same is true for other simulated attacks on other protocols (but ssh monitoring and blind DROPs are so much common to be the ones of most concern, maybe). I don't know how many relays run a NIDS (I suspect several do, actually), but it would be better to be aware of this potential self-DoS attack. The easy solution (apart from not using any IDS on relays) is to make sure that all the incoming traffic to the ORPort is always accepted, e.g. introducing an ad-hoc firewall first rule that accepts all TCP stuff from the ORPort, before processing NIDS-managed rules. Sorry if this was known already, but I couldn't find anything related by looking at the recent topics in the ML archives, and I thought it coud be useful to share. Regards

1 0

Best practice for tor-exit node when I switch internet providers?
by Chris Dagdigian 28 Jun '19

28 Jun '19

Hello, I've been running a tor exit node in the US since 2014 when I paid way too much for a comcast business internet circuit that came with static IPs and a TOS that allowed me to run servers at home. It looks like I'm going to switch providers in a month or so as there is a fiber service I can get with symmetric bandwidth, the static IP count I want and theoretically also a TOS that is also amenable to server hosting. What is the best practice if I want to keep my tor exit going but switch upstream carriers and IP addresses? I'm guessing this is going to trip a bunch of tor monitoring alerts if I just bring the server up at a new IP address. Should I change the nickname? Totally wipe and reinstall tor itself? The goal is to bring back the same exit node but not set off any alarms when the exit node with the same IP for many years suddenly shows up with a new address. -Chris

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays June 2019