July 2019 - tor-relays - lists.torproject.org

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

Measuring the Accuracy of Tor Relays' Advertised Bandwidths
by Rob Jansen 23 Sep '19

23 Sep '19

Hello relay operators! I am planning on performing an experiment on the Tor network to try to gauge the accuracy of the advertised bandwidths that relays report in their server descriptors. Briefly, the experiment involves running a speed test on every relay for a short time (about 20 seconds). Details follow. I plan to run the experiment in about 1 week. Relay operators can opt-out of the speed test by replying on this thread, and we will remove you from the list of relays to scan. Peace, love, and positivity, Rob --- Measuring the Accuracy of Tor Relays' Advertised Bandwidths Motivation ---------- The capacity of Tor relays (maximum available goodput) is an important metric. Combined with mean goodput, it allows us to compute the bandwidth utilization of individual relays as well as the entire network in aggregate. Generally, capacity is used to help balance client load across relays, and relay utilization rates help Tor make informed decisions about how to allocate resources and prioritize performance and scalability improvements. Problem ------- Currently, Tor uses a heuristic measure of unknown accuracy to estimate Tor relay capacity. Each relay keeps track of the maximum goodput it has achieved over any 10 second window in a 24 hour period. This is called the "observed bandwidth". Relays take the minimum of their "observed bandwidth" and their bandwidth rate-limiting configuration and reports the result as the "advertised bandwidth" in their server descriptors. We do not know how well the advertised bandwidth estimates the true relay capacity, but we do know that it represents a lower bound on capacity. Hypothesis ---------- The advertised bandwidth significantly underestimates the true capacity of Tor relays. On average, relays with higher true capacities will be more strongly correlated with capacity underestimation (because it will be less likely that fast relays will have sustained their full capacity over a 10 second period). Experiment ---------- A relay reports its advertised bandwidth in its server descriptor. To test how well these reported numbers represent the true capacity of a relay, we can manually perform a speed test on the relay by initiating the simultaneous download of several large data streams for a period that exceeds 10 seconds. In the report following our test, the relay will report its advertised bandwidth in its server descriptor and the results will be collected and reported by metrics.torproject.org. The experiment involves two steps: running the speed test on a relay under our control, and running the speed test on all relays in Tor network. We will first run the speed test on at least one relay that we control, in order to test that the method is effective and that we can in fact observe a change in the advertised bandwidth reported on metrics.torproject.org. Once we have confidence that our speed test is functioning correctly, and that the metrics pipeline will allow us to gather the results, we will repeat it on all relays in the network. We will conduct the speed tests while minimizing network overhead. We will use a custom client that builds 2-relay circuits. The first relay will be the target relay we are speed testing, and the second relay will be a fast exit relay that we control. We will initiate data streams between a speedtest client and server running on the same machine as our exit relay. The setup will look like: speedtest-client <--> tor-client <--> target-relay <--> exit-relay <--> speedtest-server All components will run on the same machine that we control except for the target-relay, which will rotate as we test different relays in the network. For each target relay, we plan to run the speedtest for 20 seconds in order to increase the probability that the 10 second mean goodput will reach the true capacity. We will measure each relay over a few days to ensure that our speedtest effects are reported by every relay. Although we believe that the overhead of this speed test is in line with regular usage, relay operators can opt-out of the speed test by replying on this thread. Those that opt out will be removed from our list of relays to scan. Analysis -------- Following our speedtest, we will analyze the data collected and reported by Tor metrics. We will compared the advertised bandwidth that each relay reports before our experiment to those reported during our experiment. This will help us test our hypothesis that relays' advertised bandwidth underestimates the true capacity of relays. We will run a statistical correlation analysis on the data to test the strength of the correlation between the previously reported (estimated) relay capacity and relay capacity underestimation. We will report our results to the Tor community. We expect that the results of our experiment will help Tor decide how to allocate resources and will help them plan and prioritize performance improvements. It will also provide insight into the operation of the current load balancing system, which uses advertised bandwidth to produce consensus weights.

12 37

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

DoS attack on Tor exit relay
by potlatch 08 Aug '19

08 Aug '19

Hello Tor users, Help me with a problem please. I have a small exit/backup & directory VPS in Finland [1]. This last week the server (and Tor) have been overwhelmed with non-Tor IP addresses. This may be a small version of a DoS attack. I took the server down for a few days but when I restarted it the attack was there before Tor users. Eventually, the load caused kernal crash. I noticed this last week, that my Consensus Weight had dropped from 5500 to 68. Does anyone have an efficient way to defeat this ongoing attack? --potlatch [1] 9B31F1F1C1554F9FFB3455911F82E818EF7C7883 TorExitFinland Sent with [ProtonMail](https://protonmail.com) Secure Email.

7 10

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

Running gigabit relay
by Mitar 07 Aug '19

07 Aug '19

Hi! I have Sonic Fiber which offers gigabit symmetric connection. I am thinking of using it for gigabit Tor relay, but I wonder what would be good hardware to use for something like that. Information I have found [1] is from 2010 so I wonder if there are any updates? Is there any simple small box I could use? Like Intel NUC? Information here [2] says that one can get 400 Mbps with AES-NI. And so with two processes limit per my public IP this would be around 800 Mbps then. Is this still a reasonable expectation? Do I have to care about the network card to serve gigabit (besides its being nominally gigabit)? What would be memory requirements for such a device? [1] https://www.mail-archive.com/or-talk@freehaven.net/msg14159.html [2] https://www.torservers.net/wiki/setup/server Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m

11 21

New Fallbacks from June 2019
by teor 05 Aug '19

05 Aug '19

Dear Relay Operators, Thanks to everyone who opted-in their relays as fallback directory mirrors. We rebuilt the list of fallbacks in June 2019. [0] The new list will be released in Tor 0.4.1.4-alpha/rc. It was backported to all supported Tor releases. [1] The FallbackDir flags on Consensus Health [2] and Relay Search [3] might take a week or two to update. Don't worry if your relay missed out this time. It's still helping Tor users. And we will rebuild the fallback list again in 6-12 months time. We are tracking future fallback changes in this ticket [4]. To opt-in your relays, add a comment to the ticket [4], or reply to this thread. If you have multiple relays, you can opt-in as many as you like. (We picked up to 7 per operator this time, and we may pick more next time.) T [0]: See: https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc https://trac.torproject.org/projects/tor/ticket/28793 [1]: 0.2.9, 0.3.5, 0.4.0, and 0.4.1: See https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… [2]: https://consensus-health.torproject.org/graphs.html Which uses stem's cached fallback list at: https://gitweb.torproject.org/stem.git/log/stem/cached_fallbacks.cfg [3]: For example, this relay is a new fallback, but its flag isn't shown yet: https://metrics.torproject.org/rs.html#details/1211AC1BBB8A1AF7CBA86BCE8689… [4]: https://trac.torproject.org/projects/tor/ticket/30972

2 2

Unutilized bandwidth
by Alec Larsen 01 Aug '19

01 Aug '19

Hello, I've only recently joined this list, so I apologise in advance if this is not the appropriate place for my question. For the past month, I have been operating an exit node ( 89094DFA4158C7A1583EC3A332CDCBC74A28CC0E ) from UnitedIX in Chicago, IL, US. The server has a dedicated gigabit port, and I had hoped to be able to relay around 200 TB of traffic per month, but for some reason my advertised bandwidth has been hovering at just 12 MiB/s since the first few days. The server itself is an older Supermicro PfSense server with a Xeon E3-1270v3 at 3.5ghz and 32gb of RAM. It is currently running the latest stable release of FreeBSD (12.0p7) and Tor (0.4.0.5). As far as I can tell, the machine is mostly idle: * The Tor process is the most active, and I've yet to see it go above 5% CPU. * Memory usage is under 1.5gb. * Running `speedtest-cli` (even to different servers using the `--server` option) consistently gives 600mbps+ in both directions to most destinations. * There's nothing interesting in `dmesg` or the debug logs. Does anyone have suggestions for what the bottleneck here might be? I'm happy to share more details about my configuration if that would be helpful. Thank you in advance for any help that you are willing to provide! I think Tor provides a lot of value, and I would like to provide as much bandwidth as I can to the network. -- Alec

6 7

Cherryservers (formerly balticservers) account terminated for exit relay
by Chris Kerr 31 Jul '19

31 Jul '19

I just heard from the hosting provider cherryservers.com that they are terminating my account (after 2.5 years) where I run the exit relay "ostwaldripening" (46.166.162.53), because they no longer wish to host tor exit nodes. I tried to create an account on trac.torproject.org to edit the "GoodBadISPs" wiki page, but the spam blocking stopped me from doing so.

5 4

Re: [tor-relays] Windows Relay Setup
by William Pate 31 Jul '19

31 Jul '19

Hi! Well, I certainly expected far more snarky responses. :) Thank you for the links. I'll check them out and, if I get it to work, maybe write up a guide for others. Thank you! William ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, July 14, 2019 1:44 AM, Barton Bruce <barton.bruce(a)gmail.com> wrote: > > > William, > > On 7/11/2019 6:58 PM, William Pate wrote: > > > I'm interested in hosting a Windows-based relay, if anyone can point me to a good tutorial. I've tried the most common ones. > > > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > There used to be a VIDALIA (sp?) kit that could simply be downloaded and > run on a windows machine. I then worked for an ISP/CLEC and had lots of > bandwidth so ran Vidaalia on a 64 bit Windows 7 Ultimate machine on my > desk at work. > > I never did hear why something had changed at the tor project so that > stopped working, but do remember a rude snippy condescending reply from > someone on the mailing list so I lost interest. > > I did get the head Tor guy from the Central Square Cambridge office of > TOR to come speak at a local networking group's monthly meeting we held > at a MicroSlush faclity in Burlington, MA and it was well received by a > packed audience. I think he now has left TOR and works for some ISP. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus

4 3