- tor-relays - lists.torproject.org

Reminder: Support for 0.2.4, 0.2.6, and 0.2.7 will end on 1 August 2017
by Nick Mathewson 03 Jul '17

03 Jul '17

Hi! This is a reminder that we will not be making new releases for the 0.2.4, 0.2.6, or 0.2.7 release series after 1 August 2017. If you are running one of those series, please make a plan to upgrade some time before then! 0.2.5 will still be supported until 1 May 2018. 0.2.9 support will continue until 1 Jan 2020 -- use that if you need a release that will be supported long-term. Versions 0.2.3 and earlier are not supported at all. Support for other releases (0.3.1 and 0.3.0) will continue according to the schedule at https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… . I'll send out another message like this in early July. peace, -- Nick

1 1

Bad exit node?
by tschador＠posteo.de 02 Jul '17

02 Jul '17

Today, on https://www.youtube.com I got: "An error occurred during a connection to www.youtube.com. Peer reports it experienced an internal error. Error code: SSL_ERROR_INTERNAL_ERROR_ALERT" (Browser Firefox) With another browser (Chromium) same problem - no connect. The exit node was 163.172.212.115 (https://check.torproject.org) After a while, with another exit node, no problem anymore. Temporary fault or bad exit node?

2 1

torproject debian alpha packages discontinued?
by nusenu 02 Jul '17

02 Jul '17

Hi, if you have any insides on whether there will be tor 0.3.1.x-alpha debian packages on https://deb.torproject.org/torproject.org/dists/ again sometime before September 2017 it would be great if you could share them. (the first tor 0.3.1.x alpha version got release on 2017-05-22) background: I would use that information to decide whether to keep or remove alpha support from relayor [1] (which depends on alpha packages from deb.tpo) thanks, nusenu [1] https://github.com/nusenu/ansible-relayor -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

1 1

Consensus Weight calculation
by Vort 01 Jul '17

01 Jul '17

Hello. Recently I have decided to create a new relay. After several days of waiting, I have realized that decision of Bandwidth Authorities, that my bandwidth is 1000 times lower than it should be, is pretty stable. That is bad on its own, but I was wandering - how many other relays suffers from the same problem? Since all network data is open to analysis, I have decided to calculate some statistics. As "Consensus Weight", theoretically, should correspond to relay's bandwidth, first thought was to compare it with "Advertised Bandwidth" value (assuming there not too many liars on the network). The result has revealed some anomalies: https://s8.hostingkartinok.com/uploads/images/2017/06/fed1cf8b57fc027223c8e… First, and most important, - a lot of relays have bandwidth estimate in range 0-50: 1082 of them. Second - there are incorrect estimates for popular bandwidths of 5, 10 and 20 MBits. Next question was: what estimates was actually assigned to that bandwidth spikes? Maybe all zeroes? This led me to another charts: https://s8.hostingkartinok.com/uploads/images/2017/06/8cefb70fce667a1b89c78… https://s8.hostingkartinok.com/uploads/images/2017/06/2e42634ea3f9b71df8a7f… x here is "Advertised Bandwidth", y is "Consensus Weight". I was expected to see something close to x = y line. But result was much worse. First problem (not too important) is a lot of randomness. 5 MiB relay can be easily detected as 1 MiB or 10 MiB. Second one is a thing, which, probably, steals a lot of available network bandwidth: relays with low "Advertised Bandwidth" gets much less traffic than they can handle. Almost no relay with speed < 500 KiB is rated correctly. Similarly, high-speed relays have higher weight than needed. If all 0-50KiB-estimated relays are capable of serving at least 100 KiB, fixing this problem will lead to ~ (100-25)*1082 = 82 MiB/s increase of network bandwidth. But they have even more potential, I think. Do anyone have ideas how to solve this problem? -- Vort

2 17

Tor CPU usage
by Arisbe 29 Jun '17

29 Jun '17

I have a small Tor exit relay (VPS) running at +90% CPU capacity. Memory usage is negligible. I am unable to launch ARM as the single CPU cannot process both Tor and arm. Traffic is mostly high for a small node. I have CPUsNum set at 2 in my torrc from its original setup. However, pidstat 5 -p <pid> shows that only 1 CPU is employed. lscpu shows that the VPS is allotted 2 cpus. CPU speed is around 2.44 M. I'm hoping someone has some experience with this issue and can give me advice.

2 3

Two new exit nodes online
by Tor Node Admin ＠ SechsNullDrei.org 29 Jun '17

29 Jun '17

Good morning, I have brought two new exit nodes online, ephesys0 and ephesys1 . Both are registering on atlas, and both have picked up the exit flag, so I'm providing notice for those who want to take a look at them and provide feedback on their configuration. Make your day great, Isaac, <mailto:Tor@SechsNullDrei.org> Tor(a)SechsNullDrei.org

3 3

2 beginner questions
by Torix 29 Jun '17

29 Jun '17

After running my first relay for a month at a RelayBandwidthRate of 200 KBytes/300KBytes burst, averaging 3-5 GiB per day, I upped it to 300KBytes/400 burst on the 22nd and reloaded the torrc. I don't know why I am now pushing so much more through this simple middle relay. My flags have not changed: Fast, HSDir, Running, Stable, V2Dir, Valid Here is my daily vnstat: 06/21/2017 1.83 GiB | 1.82 GiB | 3.65 GiB | 354.28 kbit/s 06/22/2017 1.98 GiB | 1.98 GiB | 3.96 GiB | 384.34 kbit/s 06/23/2017 1.68 GiB | 1.67 GiB | 3.34 GiB | 324.47 kbit/s 06/24/2017 2.33 GiB | 2.33 GiB | 4.66 GiB | 452.47 kbit/s 06/25/2017 4.00 GiB | 3.98 GiB | 7.98 GiB | 774.93 kbit/s 06/26/2017 6.45 GiB | 6.38 GiB | 12.83 GiB | 1.65 Mbit/s The number of inbound connections has gone up as well, to sometimes 3500 from a normal of 700-800. I am now on track to do about 17 Gib today. I expected to increase to maybe 6 or 7 GiB/day. What perked things up? The reload, or has the new bandwidth rate raised this realy above the average in some way? Really asking because I'm nervous about the ISP noticing, but wonder if it will just increase to the total bandwidth limit 24/7 of 26GiB/day. Hate to run it parttime to a size limit. 2nd question: Why do I have 1903 inbound, but only 132 outbound connections? Shouldn't the extra connections disappear after 10 min or so of inactivity? My flags all seem okay, and Tor would tell me if my relay was misconfigured, methinks, so this is just my not knowing enough, I hope. Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

GeoIP file
by Ian Zimmerman 28 Jun '17

28 Jun '17

How does the tor daemon read the GeoIP database file? Does it read the whole file once when starting up, or every time it needs to resolve an IP, or something in between (say, it builds an index in memory on startup and then seeks to locations in the file when looking up)? I am asking because I want to know if I need to restart, SIGHUP or in some other way kick the daemon after I install a new GeoIP file into place. -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html

3 4

申请
by 龚明福 27 Jun '17

27 Jun '17

2 3

Exit / Bad Gateway
by Sebastian Urbach 27 Jun '17

27 Jun '17

Dear list, My Exit: https://atlas.torproject.org/#details/4198BD138E5E11B15B05C826B427148CED7D9… My Consendus Weight dropped to 20 today and i found the following in notices.log: Jun 27 12:03:35.000 [warn] http status 502 ("Bad Gateway") reason unexpected while uploading descriptor to server '154.35.175.225:80'). Jun 27 12:07:35.000 [warn] Received http status code 502 ("Bad Gateway") from server '154.35.175.225:80' while fetching "/tor/server/d/C8B7BA97808F42802FCC2DF231A85ACB5B8D848A.z". I'll try again soon. Any ideas what to do or just sit it out ? -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach --------------------------------------------------------------------------- Those who surrender freedom for security will not have, nor do they deserve, either one. --------------------------------------------------------------------------- Benjamin Franklin (1706-1790)

5 5

Tor relay
by Cryptic Admin 27 Jun '17

27 Jun '17

Tor relay

1 0

申请
by 龚明福 25 Jun '17

25 Jun '17

1 0

Re: [tor-relays] I've suddenly started seeing a lot of these in our exit's logs
by tor＠t-3.net 25 Jun '17

25 Jun '17

>> On 23 Jun 2017, at 04:57, tor(a)t-3.net wrote: >> >> >> I've suddenly started seeing a lot of these in our exit's logs: >> >> Rejecting INTRODUCE1 on non-OR or non-edge circuit ...…. > >Did you upgrade the Tor version on your relay recently? >What are the old and new versions? > >(I'm guessing that this was part of the 0.2.9.11 or 0.3.0.8 bugfix, >but it's hard to tell without further info.) > >T > >-- >Tim Wilson-Brown (teor) > >teor2345 at gmail dot com >PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >ricochet:ekmygaiu4rzgsk6n >xmpp: teor at torproject dot org No changes server-side. These just starting popping up out of nowhere. Not saying they are a malfunction and the code isn't doing exactly what it's supposed to - just that it's happening. Our tor version is a bit old compared to the ones you listed. Do you know what the correct repo is that we should be using for Tor for CentOS/RedHat ?

2 1

torservers.net relays still putting tor users at risk
by nusenu 25 Jun '17

25 Jun '17

Moritz wrote (2017-06-10): > Our MyFamily statements are badly out of > sync. Will fix this next week. you are still putting tor users at risk https://nusenu.github.io/OrNetStats/ -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 2

Performance
by Sebastian Urbach 25 Jun '17

25 Jun '17

Dear list, I noticed a higher CPU load on my Exit since i recently upgraded from 0.2.9.x to 0.3.0.x and thought maybe it is just a matter of tweaking the config for 0.3.0. I could not find anything wrong and checked: https://metrics.torproject.org/torperf.html Is it just me or does that looks like a major Performance Downgrade for the whole Network since 0.3.0.x was introduced ? Looks to me like roughly 50% or more loss of Performance depending on the File size. Was that to be expected for 0.3.0.x ? -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach --------------------------------------------------------------------------- Those who surrender freedom for security will not have, nor do they deserve, either one. --------------------------------------------------------------------------- Benjamin Franklin (1706-1790)

3 3

I've suddenly started seeing a lot of these in our exit's logs
by tor＠t-3.net 22 Jun '17

22 Jun '17

I've suddenly started seeing a lot of these in our exit's logs: Rejecting INTRODUCE1 on non-OR or non-edge circuit .......

2 1

Exit node restarts itself.
by Alan 22 Jun '17

22 Jun '17

I've started to see my Exit node restart itself. There is a warning in the log pointing to a problem with OpenSSL but I don't know how to proceed. Jun 21 03:07:03.000 [notice] Tor 0.2.9.10 (git-1f6c8eda0073f464) opening new log file. Jun 21 03:07:03.619 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 1000105f: OpenSSL 1.0.1e 11 Feb 2013; running with 1000105f: OpenSSL 1.0.1e-fips 11 Feb 2013). Jun 21 03:07:03.647 [notice] Tor 0.2.9.10 (git-1f6c8eda0073f464) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1e- ips and Zlib 1.2.7. Jun 21 03:07:03.647 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Jun 21 03:07:03.647 [notice] Read configuration file "/usr/share/tor/defaults-torrc". Jun 21 03:07:03.647 [notice] Read configuration file "/etc/tor/torrc". Jun 21 03:07:03.650 [notice] Based on detected system memory, MaxMemInQueues is set to 1464 MB. You can override this by setting MaxMemInQueues by hand. Jun 21 03:07:03.650 [warn] Tor is running as an exit relay. If you did not want this behavior, please set the ExitRelay option to 0. If you do want to run an exit Relay, please set the ExitRelay option to 1 to disable this warning, and for forward compatibility. Jun 21 03:07:03.650 [notice] Opening Socks listener on 127.0.0.1:9050 Jun 21 03:07:03.650 [notice] Opening Control listener on 127.0.0.1:9051 Jun 21 03:07:03.650 [notice] Opening OR listener on 0.0.0.0:8081 Jun 21 03:07:03.651 [notice] Opening Directory listener on 0.0.0.0:8080 Jun 21 03:07:03.000 [notice] Not disabling debugger attaching for unprivileged users. Jun 21 03:07:03.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Jun 21 03:07:03.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Jun 21 03:07:03.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Jun 21 03:07:03.000 [warn] Fixing permissions on directory /var/lib/tor Jun 21 03:07:03.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECD H much faster.

4 8

keypair does not match its older value
by Alexander Nasonov 21 Jun '17

21 Jun '17

Hi, I tried moving a tor relay with offline master key to a new host but something went wrong and it printed several warnings: http status 400 ("Looks like your keypair does not match its older value.") response from dirserver What did I screw up and how to fix this problem if it happends again? I suspect it will happen again because I generate a new signing key more frequently than necessary. I create '15 days' key every week and upload it (over onion ssh connection). This scheme should be resistant to occasional upload failures but it's not clear which of the last three signing keys to use on restart. If passing the wrong key can bring down the relay I need to switch to a different scheme. I'm thinking about adding these commands to my crontab: $ crontab -l @weekly scp "${DESTDIR}/keys/ed25519_signing_cert" "${DESTDIR}/keys//ed25519_signing_secret_key" ${ONION:?}: @monthly tor --hush --keygen --SigningKeyLifetime '1 month' "${DESTDIR:?}" && {{{scp command from the previous line}}} Are there any potential problems with this approach (e.g. 28 days in Feb vs 31 days in March)? -- Alex

4 5

artikel5ev.de: tor relays and the danger of end to end correlation
by nusenu 21 Jun '17

21 Jun '17

Hi, thanks for running relays! would you mind fixing the MyFamily in your torrc files? https://nusenu.github.io/OrNetStats/ https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#see-httpsww… dc6jgk15TEST has been around since 2017-04-27 (more than a few hours or days of 'test') thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

1 0

Re: [tor-relays] Consensus Weight calculation
by Vort 21 Jun '17

21 Jun '17

>> Are there any news regarding that problem? > It's a complicated problem. > We need to work out why it is happening before we can fix it. I am not sure if I really can help with BwAuth's algorithms. But that's what I would do in such situation: First, most important thing, is a clear goal. As BwAuth's task is to make a measurements, then theirs result must be clearly defined. So, the question is - how an ideal "w" ([Consensus] Weight) looks like? Suppose we have some perfectly measured parameters for relay: perfect_measured_bandwidth (KiB/sec) and perfect_measured_latency (sec). Their exact definition can be omitted now for simplicity. Then ideal_w should be equal to: ideal_w = perfect_measured_bandwidth ideal_w = k * perfect_measured_bandwidth ideal_w = k * perfect_measured_bandwidth / perfect_measured_latency or, maybe, something else? Once this question is clear, then it is possible to see how existent implementation is far from this ideal. And here is part two: why it is different? It is some noise that can't be eliminated? Or algorithm for some reason converges to incorrect values? BwAuths have some debug information. This can help to investigate problem. There are also the possibility of doing manual checks. Which then can be compared to debug logs of BwAuth. Maybe my approach is not so good and you will choose another. But, anyway, thanks for working on this problem. -- Vort

1 0

Exit notice in Spanish
by ilv＠torproject.org 20 Jun '17

20 Jun '17

Hola, I wanted to let you know that at derechos digitales we wrote a basic tor exit notice in spanish. You can find it in [1] and a mirror in [2]. We look forward to receive feedback from the community to improve it (content, ui, etc), hoping that it could be useful to other relay operators. We have also added legal info of some countries. Feedback and contributions in this matter are welcome as well :) p.s.: someone on global-south list also told me about [3]. [1] https://0xacab.org/tortola/exit-notice [2] https://github.com/derechosdigitales/tor-exit-notice [3] https://github.com/chgans/tor-exit-notice Saludos. -i

1 0

I would lime to poste on this list
by Andree-anne Tremblay 20 Jun '17

20 Jun '17

Tank you

1 0

sharing tor relay at night or working hours ? make sense ?
by Zalezny Niezalezny 20 Jun '17

20 Jun '17

Hi, I have 100mbit Up/Down connection at home. Most of the day, my connection is not use. Mostly between 22:00-17:00. I would like to share my Internet connection for Tor. If I will setup some crontabs to start/stop my tor relay between that hours, will it work ? Does it make sense ? Will TOR network know that my relay is working only between 22:00 and 17:00 and will push some more traffic to me ? How to properly configure such a relay which is working only for a few hours per day ? Cheers Zalezny <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

7 8

libzstd and/or liblzma
by Felix 15 Jun '17

15 Jun '17

Hi nusenu thanks again for your responses ! > the context of that line is longer in the original changelog: > https://gitweb.torproject.org/tor.git/tree/ChangeLog?id=tor-0.3.1.2-alpha#n… That's where I got it from >> Might ports archivers/zstd only do the job (OR-type): >> >> Tor 0.3.1.2-alpha (git-61625b8f26384a4a) running on >> FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.5.3, >> Zlib 1.2.8, Liblzma N/A, and Libzstd 1.2.0 > > see the related comment by the FreeBSD port maintainer: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219571#c2 Good hint. When I follow the link I find the archivers/zstd port will be included which seems up to date (libzstd.so.1.2.0, 30 Jul 2016). That's what I did. Fine. Which is the right port for lzma ? When I try to include archivers/lzmalib (liblzma.so.1.1.0, 23 Sep 2008) I find it un-maintained, old and Tor does not configure for it: checking for LZMA... no configure: WARNING: Unable to find liblzma. checking for ZSTD... yes Is there a better lzma port ? -- Cheers, Felix

2 1

torservers.net: some exits became guards? (deanonymization risk)
by nusenu 15 Jun '17

15 Jun '17

Dear Torservers, are you aware that you have recently become a relay operator with end-to-end correlation (deanonymization) capabilities? (in fact you are the biggest known such operator) This is especially bad for tor clients because you are also one of the biggest tor exit operators. Some of your relays which used to be exits recently became guard-ony relays. https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#httpswwwtor… Is there anything I can help you with to fix this and reduce the risk for tor clients? thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

5 7

IP space for Tor exits - any takers?
by Moritz Bartl 12 Jun '17

12 Jun '17

Hi, After some trouble and ongoing discussions with one of our IP providers, we're again toying with the idea of registering IP space with RIPE ourselves. We can apply for a /22, which can be split into four /24s and announced at different locations (254 addresses each). Until now, we tried to avoid that, because we don't have enough "other things" to put on the same netblocks, so basically "one exit" would waste 254 precious IPv4 addresses (the full /24 address block needs to be announced from one location). But lately, with the rising amount not of abuse but of automated notifications and scared ISPs, and with the sponsoring of up to 10GE by Community-IX, we would really like at least one /24. Gareth from Brasshorn has graciously offered a spare /24 of his. The alternative would be that we apply for our own IP space, which would in turn mean that we could supply three other organizations with a /24 for their exit(s), or bridges. For bridges it is actually not that crazy, even if the range is "known" and easy to find: Most censors won't auto-detect them easily, and even if some do, the bridges are still valuable in many other locations. Also, this would allow for a bit of experimenting with tarpitting, different decoy strategies, etc. In terms of WHOIS information, the /24 can be segregated further, so an option would be to use a location where you have other uses for larger number of IP addresses. If you like the idea, and have actual use for a /24, please contact me off-list and explain what exactly you would like to do with it. If we have three other organizations (or reliable individuals) and a couple of good use cases, we're willing to apply for the /22. -- Moritz Bartl https://www.torservers.net/

1 0

Another relay is using the same name as mine.
by Alan 11 Jun '17

11 Jun '17

I just need some advice. I'm running 3 relays, one is called Andromeda. Today I find out there is another relay called Andromeda. https://atlas.torproject.org/#search/Andromeda mine is running from ip 144.217.161.119 Is it a problem with relays using the same name? Should I contact them and inform them of their error? Should I just leave it? Any advice would be very helpful. Alan.

3 2

published descriptor missing from consensus
by Scott Bennett 09 Jun '17

09 Jun '17

This time I'm stumped. I confess I have not followed this list for a long time until the last few days, so it's possible that I've run afoul of something already discussed. Late Wednesday afternoon, I restarted my relay (MYCROFTsOtherChild), which changed it from 0.3.0.6 to 0.3.0.7. That was the only change I made. It went through a normal startup and published its descriptor. After a few hours, tor noticed that its descriptor was still not in the latest consensus, so it republished it. After several more hours had passed with each consensus lacking my relay's descriptor, I made a small change to an ExitPolicy line in torrc. In the meantime, I had read some recent postings to this list and had noted some remarks regarding mismatched RSA and ED25519 keys, so I renamed /var/db/tor/keys and restarted tor again, whereupon it generated new keys and appeared to proceed normally. Once again a new descriptor was published and has since been republished and updated with no apparent problem beyond some republications being told by one or more authorities that the descriptor was rejected as "not new". Nevertheless, my relay's descriptor still has not appeared in a consensus since the last time it ran 0.3.0.6. If an authority operator would be so kind as to check the authority's logs for any errors pertaining to my relay with either its old keys or its new keys and let me know what they say, I would be grateful. Thanks for any help or suggestions of things to try. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

6 19

2017-06-07 15:37: 65 new tor exits in 30 minutes
by nusenu 08 Jun '17

08 Jun '17

DocTor [1] made me look into this. _All_ 65 relays in the following table have the following characteristics: (not shown in the table to safe some space) - OS: Linux - run two instances per IP address (the number of relays is only odd because in one case they created 3 keys per IP) - ORPort: random - DirPort: disabled - Tor Version: 0.2.9.10 - ContactInfo: None - MyFamily: None - Joined the Tor network between 2017-06-07 15:37:32 and 2017-06-07 16:08:54 (UTC) - Exit Policy summary: {u'reject': [u'25', u'119', u'135-139', u'445', u'563', u'1214', u'4661-4666', u'6346-6429', u'6699', u'6881-6999']} - table is sorted by colmns 3,1,2 (in that order) - Group diversity: - 20 distinct autonomous systems - 18 distinct countries https://gist.githubusercontent.com/nusenu/81337aed747ea5c7dec57899b0e27e94/… Relay fingerprints are at the bottom of this file. This list of relays is NOT identical to the one from DocTor (even though the number is identical (65)): [1] https://lists.torproject.org/pipermail/tor-consensus-health/2017-June/00796… https://twitter.com/nusenu_/status/872536564647198720 -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

5 5

Mail delivery failed : returning message to sender
by 6465ec09＠opayq.com 08 Jun '17

08 Jun '17

This message was created automatically by mail delivery software at Junk Email Filter. The message from "lists.torproject.org [Masked]" <FWD-737QLY3MGNAYQYGGAHICDII6EY4CAKZCFW6DEJZFHAADYYFABL5ABZTBS4AFSQCOACGAA6IMFJSMAAZAJZAAAIA=(a)opayq.com> is being returned by server opayq-outbound.junkemailfilter.com on Wed, 07 Jun 2017 21:17:32 -0700 A message that you sent could not be delivered to all of its recipients. NOTE: And this is important - Junk Email Filter is a front end spam filtering service. We accept email for our customers, filter it, and pass the good email on. Sometimes when we forward email as good the server we forward to rejects it. Generally if you are getting this message it is because the server we forwarded to * NOT JUNK EMAIL FILTER * has rejected the message. If you see below the phrase "error from remote mail server" then it is the server who we are forwarding to, NOT US who is rejecting the email. Read the reason carefully and see if you can correct the cause of the rejection. The following address(es) failed: m.terlinde(a)gmx.de host mx01.emig.gmx.net [212.227.17.5] SMTP error from remote mail server after HELO opayq-out-00.junkemailfilter.com opayq-outbound.ctyme.com: 500 Syntax error, command unrecognized

1 0

libzstd and/or liblzma
by Felix 07 Jun '17

07 Jun '17

>> Can somebody please help me understand the change log for >> 3.1.x: "Support for these algorithms requires that tor is >> built with the libzstd and/or >> liblzma libraries available." Is it AND or OR or something whatever >> different ? > > > Hi! Let me try to clear it up: > > If Tor is built with liblzma available, it will use liblzma when > appropriate. The lzma format is expensive to calculate, but it > provides very good compression, so we only use it for cases when we > can compress something once and server it many many times -- like > consensus documents, or consensus diffs. > > If Tor is built with libzstd available, it will use libzstd when > appropriate. The zstd format is cheap to calculate, but appears to > provide better compression than zlib on our data. > > If Tor is built with both libraries available, it will use either one > when appropriate. > > Of course, we can only use these compression formats when both sides > support them. Thanks. Clear to me. So 'Liblzma N/A' should not be an issue. -- Cheers Felix

1 0

libzstd and/or liblzma
by Felix 07 Jun '17

07 Jun '17

Hi everybody Can somebody please help me understand the change log for 3.1.x: "Support for these algorithms requires that tor is built with the libzstd and/or liblzma libraries available." Is it AND or OR or something whatever different ? Might ports archivers/zstd only do the job (OR-type): Tor 0.3.1.2-alpha (git-61625b8f26384a4a) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.5.3, Zlib 1.2.8, Liblzma N/A, and Libzstd 1.2.0 -- (And why says the notice message "OpenSSL LibreSSL" ?) Cheers, Felix

3 2

Ahiker shutting down
by Ian Zimmerman 05 Jun '17

05 Jun '17

Hello, sadly I have to terminate my relay because it seems to interfere with the quotidian use of my server. I'll look for a way to help the community in other ways. -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html

2 1

Only 3 bw auths available
by Felix 03 Jun '17

03 Jun '17

Uhh. Wasn't there a transition to use self reported bw below some threshold number ? -- Cheers, Felix

2 1

Who is running the two biggest Exits in the network?
by Paul 01 Jun '17

01 Jun '17

Since about mid April there are just two similar Exits making up now about 4.5% exit probability together. Located in Panama, run in the okservers.net network, AS395978 ,they don’t give up any further information about themselves. Personally I would feel better at least having a contact or even better, knowing who is giving that much effort. Probably a MyFamily configuration should be placed as well? https://atlas.torproject.org/#details/29C92C854E0F6652A77F3A8B231D693299396… https://atlas.torproject.org/#details/2CA4B2F36C2DDECFCB0B5A0D3300ED30E68E2… Paul

6 10

Questions about OfflineMasterKey
by Cristian Consonni 31 May '17

31 May '17

Hi, On 18/05/2017 10:45, nusenu wrote:>> Currently, my server hosting kitten1 and kitten2 (tor guard and fallback >> directory) is under seizure since 14/05 11h. butplease revoke >> immediatly kitten1 & kitten2 tor node. >> Those nodes are also fallback directory. > > I don't know any context or background but if you fear this could happen end to use tor's OfflineMasterKey feature (without > copying the master key to the server) with a short keylifetime (i.e. 7 > days), especially if it is a fallback dir > (which requires a tor source code change to remove it). This feature is interesting and I did not know about it. However, I have been reading the documentation page[1] and I have the impression that the more I read the less I understand how it works. If I look inside the DataDir of one of my relays - a standard Debian install - see this: ``` ed25519_master_id_public_key ed25519_master_id_secret_key ed25519_signing_cert ed25519_signing_secret_key secret_id_key secret_onion_key secret_onion_key_ntor secret_onion_key_ntor.old secret_onion_key.old ``` So, here some of the things I think I have understood: * Tor uses a ed25519 key to generate the other keys need to decrypt incoming traffic and route it to its next destination on the network. I don't know how this works in practice, but probably it is too much detail at the moment. * In the standard install the master key is the `ed25519_master_id_secret_key` above, which has no passphrase. * If in `torrc` we declare `OfflineMasterKey 1` then the `ed25519_master_id_secret_key` will not reside anymore on the relay but on a separate machine. * In the process of generating the master key (with the command `tor --keygen`, all the files above will be generated. * To run the node with `OfflineMasterKey 1` you need to copy all the files generated in the previous step *with the exception of the master key*. I had also a few questions: * is the above correct? * if I use the offline master key protected with a passphrase will I need to input the passphrase every time I restart Tor (I have in mind what Apache does when you restart it and have certificates protected with a passphrase)? * Assuming that I am going to use a separate machine to generate the master key I need to make sure that the version of Tor on the machine that I use to generate the key and the relay? Thanks for your help. Cristian [1]: https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/OfflineK…

3 5

Encrypting the DataDir
by Cristian Consonni 31 May '17

31 May '17

On 15/05/2017 12:21, aeris wrote: > Private key are under encrypted volume and may be protected On 21/05/2017 10:02, Roger Dingledine wrote: > On Sun, May 21, 2017 at 09:12:39AM +0200, Petrusko wrote: >> @aeris, do they ask you to uncrypt the volume ? (good luck to you...) >> What can be the best ? Uncrypt the relay to help police when asking, >> when this relay is only a relay and storing nothing else ? > > That's actually why the torservers.net people suggest *not* using disk > encryption. Having no barriers makes it much easier for the police to > realize that there's nothing useful to them. See also point two of > https://blog.torproject.org/blog/trip-report-tor-trainings-dutch-and-belgia… >From the Tor Exit Guidelines: «Disk encryption might be useful to protect your node keys, but on the other hand unencrypted machines are easier to "audit" if required. We feel it's best to be able to easily show that you do Tor exiting, and nothing else (on that IP or server).» https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines I was wondering if the argument about not encrypting the disk applies just to the full-disk encryption or if it is applicable also to the caso of encrypting just the DataDir on a fairly small file-based volume (say 100MB). In the second case, how big can the DataDir get? Cristian

5 6

reminder: tor 0.3.1.1-alpha is _not_ recommended (known bug)
by nusenu 31 May '17

31 May '17

Since there were only 8 relays running 0.3.1.1-alpha I didn't bother to state this here, but since the number is rising since yesterday I just wanted to remind you that tor 0.3.1.1-alpha contains a bug that makes this not a good version to use. In the worst case (unlikely) you would publish a limited amount of memory via your relay descriptor https://trac.torproject.org/projects/tor/ticket/22368#comment:7 https://trac.torproject.org/projects/tor/ticket/22378 Relays currently using tor 0.3.1.1-alpha (excluding Roger's): +------------------+------------------------------------------+ | nickname | contact | +------------------+------------------------------------------+ | Quincy | NULL | | ss666 | NULL | | sorryitsslow | NULL | | artiX | NULL | | ELECTRICSHEEP | NULL | | dahool | NULL | | BabylonNetwork01 | Babylon Network | noc <AT> babylon <DOT> | | BabylonNetwork03 | Babylon Network | noc <AT> babylon <DOT> | | BabylonNetwork00 | Babylon Network | noc <AT> babylon <DOT> | | BabylonNetwork02 | Babylon Network | noc <AT> babylon <DOT> | | Gentoo | gentoo.intel(a)gmail.com | | 0x000000000 | https://ban.ai | | HeirloomReaper | James Taylor <tor AT fornoreason dot net | | ireadconf | torrelay(a)fh-biergarten.de - 1QCHdyhPHLrK | +------------------+------------------------------------------+ If you are eager to run alpha level tor versions to uncover and report bugs early that is great but you might want to wait for tor 0.3.1.2-alpha or run master builds after https://gitweb.torproject.org/tor.git/commit/?id=ab9976b7245f05a97e0285265c… https://deb.torproject.org/torproject.org/dists/tor-nightly-master-stretch stay safe, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 3

Question about circuit/path live time
by Olaf Grimm 31 May '17

31 May '17

Dear readers ! For my relays I looking for a torrc parameter to reduce the circuit live time from default of 10 minutes to about 5 minutes. My intension: I dont' know is the point of time to switch the path between relays synchronized. An overlap (or different switching time) will reduce the path live time to less than 10 minutes. This is ok for me, because the circuit analysis time for attackers is less than 10 minutes (traceroute...). Synchronized relays keeps a whole circuit path open for 10 minutes, from guard to the exit. Am I right? Am I right with my intension to change the default circuit live time or is this not necessary? A short answer would be ok. Assuming torrc parameter: MaxCircuitDirtiness NUM (Default: 10 minutes) The backgroud of the story (and why I want to generate more noise): Last year, on July 19, my exit relay was seized at home. I knew about the danger, but I ignored it. According to the police, my relay was abused for about 5 months, again with the same (evil) web server as the target. I am assuming my Exit Relay was explicitly selected as an exit. To protect the relay operators, you might want to remove this function. A targeted compromising of an operator must not be possible. The police photographed some of the current connections displayed with ARM. A test with ARM showed an indication of a seemingly complete circuit from the guard to the exit. I see Source -> Target, Guard, Middle, Exit. I'm not sure, but I get a bad feeling. Please tell me that my interpretation of the displayed content in ARM is wrong. For the time being, I only have 2 Middle nodes as VPS online. Later, after the completion of the law procedure, I switch the two VPS middle nodes back to Exit Relays (Provider Keyweb and FlokiNET). The third middle node at home remains only a middle node. I swear this. Best regards! Olaf (node49/node49a/node49b)

2 1

Neldoreth relay seized ?
by aeris 30 May '17

30 May '17

Dear Neldoreth relay’s operator, This day, we were informed of a Tor node seizure at FirstHeberg during the 13-14/05, related to Wanacry infection of the french company Renault. https://www.nextinpact.com/news/104398-wannacrypt-nud-tor-saisi-chez-firsth… FirstHeberg say the seized node was "traffic analyzed" during some times before being shuting down for content cloning and drive given to cops. They are at least 5 others relays seized under the same case at OVH and Online providers. https://www.nextinpact.com/news/104302-wannacrypt-nuds-tor-saisis-par-autor… https://gist.github.com/nusenu/3d7bbeb7c97af591d65003b4bfe70021/ After consensus investigation, it seems your Neldoreth node is the only hosted at FirstHeberg with a downtime during this timeframe (from 14/05 18:00 to 17/05 14:00). This node is currently running, but lost its guard flag since restart. Could you confirm if your node was seized or not ? If seizure confirmed or suspected, your private key is probably no more safe, so please report your fingerprint to bad-relays(a)lists.torproject.org for blacklisting to avoid reusage, and renew your private key. Regards -- Aeris https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/

3 2

New exit node best practices
by Isaac Grover, Aileron I.T. 29 May '17

29 May '17

Good evening, After many months of running a relay, I'm planning to establish up a family of exit nodes with geographically diverse VPS providers, shying away from the list of the most heavily used Tor friendly providers. Several questions: - Does establishing a family increase the risk of the nodes being taken down en masse? - Do you suggest providing ample contact information for the node directory, as opposed to little or none? - I'm being very upfront with sales@ regarding my purpose before signing up, and making sure they're okay with it. What questions should I be asking to be sure they'll be Tor friendly before shutting down my exit nodes? Make your day great, Isaac Grover, Senior I.T. Consultant Aileron I.T. - "Practical & Proactive I.T. Solutions" O: 715-377-0440, F:715-690-1029, W: www.aileronit.com

5 4

Memory Problems with tor releay
by tor-relay.dirk＠o.banes.ch 27 May '17

27 May '17

Dear all, we are operating two exit nodes with each two tor processes out of Switzerland. The nodes worked quite stable until about 2-3 weeks ago. Since then we experience frequent disruptions (Up to several times a day). This is caused by a significant rise in memory consumption by the tor processes and ends with a tor process being killed by the Linux Kernel: May 22 00:30:43 tor2 kernel: [2257156.134100] Killed process 40964 (tor) total-vm:448088kB, anon-rss:0kB, file-rss:0kB The systems are physical machines with Ubuntu 14.04.5 LTS with 4 GB of memory. This was sufficient the last 2 years. For more details a sample of this behavior is documented in a Ticket [1]. Tor project team is researching but until now no hints lead to an improvement. Due to a tweet last week [2] and the follow up discussion with another operator I became suspicious that is not just just us having a problem rather it cloud be more common. Therefore here the question to you all - do you experience some strange behavior like described in the ticket as well ? Please let me know if so. If not - maybe it is just an unfortunate coincidence and we will end up make a clean install of both server hoping the problem will go away. best regards Dirk [1] https://trac.torproject.org/projects/tor/ticket/22255 [2]https://twitter.com/FrennVunDerEnn/status/864583496072876034

10 15

neel@neelc.org relays: MyFamily and tor version update needed
by nusenu 26 May '17

26 May '17

Hi Neel, thanks for running FreeBSD tor relays. Your new relay added yesterday is not yet in sync with your other relays yet, please consider updating the MyFamily configuration to help protect tor clients from using a single operator in entry and exit position: https://atlas.torproject.org/#details/0D8211D34F29F51D690303E319766E1B7C28B… https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#neel-chauha… You also might want to update these relays running a tor version that is vulnerable to TROVE-2017-002: https://atlas.torproject.org/#details/1602E42D1DE3C7B3EF042F357F906DE55FA6C… https://atlas.torproject.org/#details/D5B8C38539C509380767D4DE20DE84CF84EE8… tor 0.3.0.7 contains the fix for TROVE-2017-002 and can be installed via FreeBSD's pkg command. thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

1 0

exit relay consensus weight
by Arisbe 26 May '17

26 May '17

Hello relay ops, I just made an interesting observation that I thought I would share. Yesterday I started a VPS exit relay at a well known hosting company in Moldova [0]. Within 24 hours I saw the consensus weight exceed 10000. The relay is bandwidth limited to 10 MiB/s. Not that I'm complaining! So it begs the question: Is there not enough exit relays on the Tor network? Arisbe [0] B06F093A3D4DFAD3E923F4F28A74901BD4F74EB1

2 1

Legal Status of Relays Worldwide [was: kittens seized]
by grarpamp 25 May '17

25 May '17

>>> That's actually why the torservers.net people suggest *not* using disk >>> encryption. Having no barriers makes it much easier for the police to >>> realize that there's nothing useful to them. >> This falling over may perhaps not be preferred by operators who like to >> create wins in the crypto war. You want police to go get their warrants, >> waste their time and money, just to prove nothing upon decrypt... >> then you have higher recorded, thus marketable, percent of nothing >> found among all forced decrypt cases. Instead of closer to 100% >> of such cases just confirming already forgone criminal cases. >> Having higher barriers and costs and demonstrably less fruit >> ratio can make such seizures more unlikely in first place. > Can they force an operator to decrypt, if he lives in other country > which is non-US and non-EU (e.g. Russia or China)? Depends if hosting country can extradite, or threat influence at things of value such as bank accounts, travel bans, people, etc. > Does it make sense > to run nodes in countries you don't live in or visit? If poor odds or afraid of such things, the farther distant and / or opposite legally, politically, logically and physically the better. > What happens if an operator themselves is anonymous? They lose the remaining hosting contract worth of bitcoin, get the account / card canceled, nym blacklisted, etc. For only running an exit / relay and nothing else... Policy / nuisance shutdowns by the hoster do happen often, nodes just move and redeployed elsewhere. Detainer for questioning, are rare, oops, you're free to go. Raids and confiscation, are rare, and property seems to be returned. Actual arrests / night in jail / charges, are even rarer, oops you're free to go. Charges that go to court, are extremely rare. Probably no one has *ever* been convicted that we know of? Because only running an exit / relay and nothing else, seems to be legal everywhere. (If it is illegal somewhere, then the operator is at fault for breaking that law.) And traffic passing through relays seems to have "ISP style" legal exceptions everywhere, that even cover "torts", so long as operators are not in business of inspecting or moderating. Which is why everything above is marked "rare". If you know of places where... a) relays themselves are illegal or b) ISP style exceptions do not exist ... you should definitely reply with such a list. Real problems are rare, and running relays is fun :) Legal environments typically apply equally so once you know your environment you can always add other overlay networks / services / nodes into to the mix if you're bored or have unused bandwidth in your contract: I2P, CJDNS, GNUNet, Freenet, Pond, VPNGate, XMPP / IRC, Remailers, Crypto Currencies, IPFS, etc...

4 4

Upgrading a relay and changing IP address
by Cristian Consonni 24 May '17

24 May '17

Hi, On 18/05/2017 01:56, Gunnar Wolf wrote: > Cristian Consonni dijo [Wed, May 17, 2017 at 05:04:29PM +0200]: >> AS you can see from the Debian package page[1] the latest available >> version of Tor packaged for Wheezy is 0.2.4.27-3, which to me looks >> quite behind either 0.2.5.12-4 available in Jessie (stable) or the >> 0.2.9.X series available through backports or testing. >> >> What's the best to do in this cases? >> * Should I start updating tor manually? >> * Should I update Debian on the server? (which could well me start with >> a fresh install? >> * Is it ok like it is now, provided that the system is updated? > > While Debian Wheezy (7, our "oldstable" release) still has security > support via LTS¹, it is not recommended to run a Tor relay with such > old packages. In fact, not even the version available in Jessie (8, > our "stable" release - 0.2.5.12-4) is recommended nowadays. > > I suggest you to update to _at least_ Jessie and use the version in > backports (depends on your sysadmining, but if your machine's only use > is to run a Tor node, I'd suggest installing Stretch, 9, which has > 0.2.9.9-1). I am running the relays on VPS providers so, I can choose (only) among the versions of Debian that are provided by the services as templates. When Stretch is release I will see if they make it available, in a reasonable time. I am settled anyhow to upgrade the nodes as soon as the new Debian version is released and I have a question. I have read that I can move the node keys when upgrading[1] and I will do that. One thing that will change with a fresh install is the IP address of the nodes. So, I was wondering, in general is a good thing to keep the same IP or changing it? Because in any case, I could try and do a dist-upgrade[2] so that I keep the old IP. I have also discovered now that DigitalOcean, one of the providers I use, provides a kernel-management interface[3] that could make the process easier. So, which is preferable between the two processes where one has the advantage of keeping the same IP (dist-upgrade) and the other not (fresh install)? Of course, I am assuming that I will be able to complete any of the two processes successfully. Cristian [1]: https://www.torproject.org/docs/faq.html.en#UpgradeOrMove [2]: https://www.debian.org/releases/stable/amd64/release-notes/ [3]: https://www.digitalocean.com/community/tutorials/how-to-update-a-digitaloce…

5 9

Kitten1 and kitten2 compromised (guard/hs/fallback directory)
by aeris 24 May '17

24 May '17

Dear Tor Project, Currently, my server hosting kitten1 and kitten2 (tor guard and fallback directory) is under seizure since 14/05 11h. Private key are under encrypted volume and may be protected, but please revoke immediatly kitten1 & kitten2 tor node. Those nodes are also fallback directory. Regards, -- Aeris https://imirhil.fr/ Protégez votre vie privée, chiffrez vos communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/

18 21

Problem starting 0.3.0.7 on Ubuntu?
by Alexander Dietrich 23 May '17

23 May '17

Hello, did anyone else run into a problem when upgrading from 0.2.9.10 to 0.3.0.7 on Ubuntu? Tor is no longer starting, with these messages in syslog: [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". [notice] Read configuration file "/etc/tor/torrc". [warn] Directory /var/lib/tor/SERVICE_NAME/ cannot be read: Permission denied [warn] Checking service directory /var/lib/tor/SERVICE_NAME/ failed. [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details. [err] Reading config failed--see warnings above. The permissions on /var/lib/tor/SERVICE_NAME/ are "rwx--S---" and it's owned by debian-tor, which worked for 0.2.9.10. Thanks, Alexander -- PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB

4 8

(FWD) [tor-announce] Tor 0.3.0.7 is released, with a medium security fix for relays
by Roger Dingledine 21 May '17

21 May '17

For those of you who are not on tor-announce... now would be a good time to remember to subscribe to tor-announce. :) --Roger ----- Forwarded message from Nick Mathewson <nickm(a)torproject.org> ----- Date: Mon, 15 May 2017 18:57:59 -0400 From: Nick Mathewson <nickm(a)torproject.org> To: tor-announce(a)lists.torproject.org Subject: [tor-announce] Tor 0.3.0.7 is released, with a medium security fix for relays Hi, all! There's a new Tor release (0.3.0.7) available on the website. It fixes a bug affecting relays running earlier versions of 0.3.0.x that could allow attackers to trigger an assertion failure on those relays. Clients are not affected; neither are relays running versions before 0.3.0.x. If you're running a relay with one of the affected versions, you should upgrade. Source is available on the website now; packages should be available over the next several days. =========== Changes in version 0.3.0.7 - 2017-05-15 Tor 0.3.0.7 fixes a medium-severity security bug in earlier versions of Tor 0.3.0.x, where an attacker could cause a Tor relay process to exit. Relays running earlier versions of Tor 0.3.0.x should upgrade; clients are not affected. o Major bugfixes (hidden service directory, security): - Fix an assertion failure in the hidden service directory code, which could be used by an attacker to remotely cause a Tor relay process to exit. Relays running earlier versions of Tor 0.3.0.x should upgrade. should upgrade. This security issue is tracked as TROVE-2017-002. Fixes bug 22246; bugfix on 0.3.0.1-alpha. o Minor features: - Update geoip and geoip6 to the May 2 2017 Maxmind GeoLite2 Country database. o Minor features (future-proofing): - Tor no longer refuses to download microdescriptors or descriptors if they are listed as "published in the future". This change will eventually allow us to stop listing meaningful "published" dates in microdescriptor consensuses, and thereby allow us to reduce the resources required to download consensus diffs by over 50%. Implements part of ticket 21642; implements part of proposal 275. o Minor bugfixes (Linux seccomp2 sandbox): - The getpid() system call is now permitted under the Linux seccomp2 sandbox, to avoid crashing with versions of OpenSSL (and other libraries) that attempt to learn the process's PID by using the syscall rather than the VDSO code. Fixes bug 21943; bugfix on 0.2.5.1-alpha. _______________________________________________ tor-announce mailing list tor-announce(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce ----- End forwarded message -----

10 18

OrNetStats
by nusenu 20 May '17

20 May '17

Hi, if you want to compare your relay(s) with other operators: https://nusenu.github.io/OrNetStats/ Entries on the page link to compass (if you run more than one relay) or directly to atlas if you operate just one. regards, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 3