- tor-relays - lists.torproject.org

Re: [tor-relays] Improving Relay IPv6 - RIPE Grant
by ILikeTor 18 Mar '20

18 Mar '20

Hi, I was wondering how you will implement IPv6-only relays. What limits will you set on how many relays can be per /(something)? Will you allow only two relays per /64, for example? Do you have any plans for that already?

3 2

Migrating to a new data center
by niftybunny 17 Mar '20

17 Mar '20

Comrades! Today the united rodent liberation army transitioned to a new data center in order to more effectively fight for privacy, security and freedom for every fluffy creature on this earth! We will work paw-in-paw to create a brighter future not only for us, but for every privacy-minded critter everywhere. Together we hop and together we fight! We are now online with 60cores/120 threads (Xeon), 384 gigabyte ram and a 60 gigabit connection. We will boost our puny traffic in the next weeks. For full transparency we also release these pictures of me and our QA team working hard to bring only the best of the best to you: https://i.imgur.com/iKh61E8.jpg <https://i.imgur.com/iKh61E8.jpg> https://i.imgur.com/4gnzncD.jpg <https://i.imgur.com/4gnzncD.jpg> https://i.imgur.com/DD0uaGC.jpg <https://i.imgur.com/DD0uaGC.jpg> https://i.imgur.com/VG7pm3S.jpg <https://i.imgur.com/VG7pm3S.jpg> https://i.imgur.com/wgRv8FU.jpg <https://i.imgur.com/wgRv8FU.jpg> niftybunny

4 5

Port Forwarding Question
by William Pate 17 Mar '20

17 Mar '20

This constantly trips me up. In my modem settings, I'm offered these options for port forwarding. I know I need to open 9001, but what do I enter into the external port fields? Thank you! William Pate willpate(a)pm.me 512-947-3311 inadequate.net

4 5

Fwd: Upcoming Tor security releases to fix a denial-of-service issue
by Nick Mathewson 16 Mar '20

16 Mar '20

---------- Forwarded message --------- From: Nick Mathewson <nickm(a)torproject.org> Date: Mon, Mar 16, 2020 at 1:25 PM Subject: Upcoming Tor security releases to fix a denial-of-service issue To: <tor-talk(a)lists.torproject.org> Hello! Some time this week, we currently plan to put out a set of security updates for all supported versions of Tor. These releases will fix a pair of denial-of-service bugs: one that we are classifying at "low" severity, and one that we are classifying at "high" severity. Our recommendation will be for everybody, including relays and clients, to upgrade once packages are available for their platforms. Although these vulnerabilities are "only" denial-of-service issues, any denial-of-service attack against Tor could be leveraged by an attacker to aid in a traffic analysis attack. To the best of our knowledge, these vulnerabilities are not being exploited in the wild. Currently supported release series are 0.3.5, 0.4.1, 0.4.2, and 0.4.3 (alpha). If you have not yet upgraded to one of those, the time to do so is soon. For our policy and process for handing security issues, please see: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Securit… best wishes, -- Nick

1 0

Consensus Weight Dropping/Authority Issues?
by John Ricketts 16 Mar '20

16 Mar '20

Hello, I have been watching the consensus weight and bandwidth of all of my 50 exit nodes drop consistently over the past few months. I have not made any hardware changes in my data center and actual customers have not complained about any performance issues. Operating systems and Tor version are up to date. I'm dedicating a significant portion of bandwidth to these nodes - 10gbit/sec. Am I having issues with the bandwidth authorities? I'm growing frustrated with my performance to resources ratio, I should be doing far better than this. Please throw ideas at me - open to any ideas. Thanks! John Quintex Alliance Consulting

7 11

tor relay
by Станислав 14 Mar '20

14 Mar '20

hi.I start second instance of tor, but for some reason it stopped working.after updating the firmware on board pc engines apu2 Mar 09 13:48:46.000 [notice] Bootstrapped 0% (starting): Starting Mar 09 13:49:03.000 [notice] Starting with guard context "default" Mar 09 13:49:03.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) Mar 09 13:49:03.000 [warn] Couldn't set up any working nameservers. Network not up yet? Will try again soon. Mar 09 13:49:03.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Mar 09 13:49:04.000 [notice] Bootstrapped 5% (conn): Connecting to a relay Mar 09 13:49:04.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) Mar 09 13:49:04.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay Mar 09 13:49:04.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay Mar 09 13:49:05.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done Mar 09 13:49:05.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Mar 09 13:49:05.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Mar 09 13:49:05.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit Mar 09 13:49:06.000 [notice] Bootstrapped 100% (done): Done Mar 09 13:50:05.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Publishing server descriptor. Mar 09 13:50:08.000 [notice] Performing bandwidth self-test...done. Mar 09 13:51:32.000 [notice] Received reload signal (hup). Reloading config and resetting internal state. Mar 09 13:51:32.000 [notice] Read configuration file "/etc/tor/torrc1". Mar 09 13:51:32.000 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong. Mar 09 13:51:32.000 [warn] MyFamily is set but ContactInfo is not configured. ContactInfo should always be set when MyFamily option is too. Mar 09 13:51:32.000 [notice] Tor 0.4.2.5 opening log file. Mar 09 13:51:32.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) Mar 09 13:51:32.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.4.2.5 ) Mar 09 13:51:32.000 [err] Reading config failed--see warnings above. For usage, try -h. Mar 09 13:51:32.000 [warn] Restart failed (config error?). Exiting. С уважением, Станислав

7 12

Relays will be getting clock skew warnings today
by Roger Dingledine 14 Mar '20

14 Mar '20

Hi folks! One of the directory authorities, dizum, has a wrong clock today. And it is causing warning lines for every relay who interacts with it. :( The log lines will look like this: Mar 14 16:17:40.121 [warn] Received directory with skewed time (DIRSERV:45.66.33.45:80): It seems that our clock is behind by 2 hours, 0 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. I contacted the directory authority operator and he is working on fixing it. Hopefully he'll get it fixed today, and we can point the flood of concerned mails to this thread. :) Thanks, --Roger

1 0

Any tor relay watchdog services?
by Layer13 13 Mar '20

13 Mar '20

Hello, I'm writing to query about tor relay watchdogs and ask if there are any services to check if tor reachable from the internet and if not it would send me an automated email telling me that my relay is down. A little bit of backstory on why I need this: so a couple of days ago (13 to be exact) my server had an issue and rebooted, since that reboot I didn't start my relay node and it was down for 13 days until I noticed it today.

3 2

website support
by potlatch 13 Mar '20

13 Mar '20

Hello Tor, I have a few exit relays on the Tor network but generally I'm flying blind. Why isn't there an index of tor relays that can be accessed? Why isn't the tor access via it's website able to deliver me to the software pages? Why is the graphic display of tor connections over 5-years old? I thought tor was expert in data delivery and security. potlatch(a)protonmail.com Sent with [ProtonMail](https://protonmail.com) Secure Email.

4 3

tor relay
by Станислав 10 Mar '20

10 Mar '20

system openwrt.I have a bunch of odhcpd+unbound.on a unbound works dns-over-tls in end face log torrc these errors.are what could be the problem? the unbound is not configured correctly. Mar 09 15:13:37.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) Mar 09 15:23:37.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) Mar 09 15:33:37.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) Mar 09 15:43:37.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) Mar 09 15:53:37.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) Mar 09 16:03:37.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) Mar 09 16:13:37.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) Mar 09 16:23:37.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) Mar 09 16:33:37.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) Mar 09 16:43:37.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (1) С уважением, Станислав

2 1

Re: [tor-relays] Dirport9030
by Nuno Rego 10 Mar '20

10 Mar '20

Problem solved. Cumprimentos; -- Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: https://tutanota.com Mar 4, 2020, 21:37 by : > I have a problem.> > I am learning, and I have 4 active relays.> > I used the same configuration on the 4. Recently 2 of them lost the Guard, HSdir and V2Dir flags.> > On the page > https://metrics.torproject.org/rs.html#search/TugaOnion> I see that DirPort is 0 instead of 9030. I haven't changed anything, and in the relay configuration there is 9030. Any suggestions on how to solve the problem> > ? > > Cumprimentos; > > -- > Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: > https://tutanota.com >

3 3

Re: [tor-relays] How to Limit Bridge Traffic
by entensaison＠use.startmail.com 06 Mar '20

06 Mar '20

Hi, On Thursday, March 5, 2020 at 8:24 PM, Imre Jonk <imre(a)imrejonk.nl> wrote: > Hi Eddie, > > On Wed, 2020-03-04 at 12:34 -0800, Eddie wrote: >> Does BandwidthRate apply to bridges. I can (hopefully) guess that >> RelayBandwidth doesn't. >> Does the AccountingMax apply. > I am almost certain that all three options apply to bridges as well. > Note that BandwidthRate applies to all TCP data (not the TCP headers > or > DNS traffic), while RelayBandwidth* applies to the _relayed traffic_ > only. > >> I noticed the following in the manual: >> >> If you have bandwidth cost issues, enabling hibernation is >> preferable >> to setting a low bandwidth, since it provides users with a >> collection >> of fast servers that are up some of the time, which is more useful >> than a set of slow servers that are always "available". >> >> Does that advice apply equally to bridges, assuming that the >> Accounting options do apply. Or would it more advantageous for a >> bridge to be constantly available, as switching bridges isn't as >> seamless as switching relays. > That's an interesting question. Bridges are required to provide at > least 1 Mbit/s bandwidth, but I can't find anything related to uptime > requirements (except for the two hours a day minimum). I'd say that > the > advice therefore also applies to bridges. The Tor client software can > be configured to use multiple bridges. I would say the recommendation to use AccountingMax does not apply for bridges. It's just a subjective impression but there are often people complaining that most bridges they get handed out don't work or stop working after a short time. Some of these people end up believing that they are unable to use Tor at all from their location, because their adversary successfully detected the bridge. (Which might be true in some cases.) In order to avoid confusion for people who depend on using bridges it seems to make more sense to limit the bandwith instead.

1 0

How to Limit Bridge Traffic
by Eddie 05 Mar '20

05 Mar '20

Hi, I'm quite happy to continue to run a couple of bridges on my VPC, but I need to understand how to manage the bandwidth so I'm not being charged for exceeding it's monthly allocation. Does BandwidthRate apply to bridges. I can (hopefully) guess that RelayBandwidth doesn't. Does the AccountingMax apply. I noticed the following in the manual: If you have bandwidth cost issues, enabling hibernation is preferable to setting a low bandwidth, since it provides users with a collection of fast servers that are up some of the time, which is more useful than a set of slow servers that are always "available". Does that advice apply equally to bridges, assuming that the Accounting options do apply. Or would it more advantageous for a bridge to be constantly available, as switching bridges isn't as seamless as switching relays. Cheers.

2 1

playing around with relay flags?
by Basajauntxo 05 Mar '20

05 Mar '20

My relay, 83A802311F37647C243CF06970BA111E0E543CCE has been changing flags from "fast, running. stable", to "none" without and apparent reasong to trigger such changes. It can take up to 2 Mb/s connections and traffic up tp 6GB daily. The thing runs on a metered connection. If for some reason these specs have become too low please specify. Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 2

Should new exit relays be probed for public DNS resolvers
by Nathaniel Suchy 05 Mar '20

05 Mar '20

There has been discussion over the past several years that the Tor network should not use public DNS resolver as it has security implications on the Tor network (https://medium.com/@nusenu/who-controls-tors-dns-traffic-a74a7632e8ca) Should new Tor Exit Relays be probed and not included in the consensus until they're running their own DNS resolver and not relying on a public one?

4 6

Dirport9030
by Nuno Rego 04 Mar '20

04 Mar '20

I have a problem. I am learning, and I have 4 active relays. I used the same configuration on the 4. Recently 2 of them lost the Guard, HSdir and V2Dir flags. On the page https://metrics.torproject.org/rs.html#search/TugaOnion I see that DirPort is 0 instead of 9030. I haven't changed anything, and in the relay configuration there is 9030. Any suggestions on how to solve the problem ? Cumprimentos; -- Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: https://tutanota.com

1 0

Stable flag not appearing on my bridge.
by Keifer Bly 01 Mar '20

01 Mar '20

Hi all, So my bridge at https://metrics.torproject.org/rs.html#details/386E99371B8CD938248940B754F1… Is not getting the stable flag despite being running for several weeks with only minor interruption in between. Is the stable flag no longer used for bridges? Thank you. -- --Keifer

2 1

So here is my working script of automatically starting windows tor relays bridges when windows starts, and trying to write script to auto update.
by Keifer Bly 28 Feb '20

28 Feb '20

Hi all, So here is my script for automatically starting a Windows (Expert bundle based) relay or bridge when windows starts. Open a new notepad document. Then add the following to it: Cd c:/pathwheretorexpertbundleisindtalled tor.exe -f torrc.txt (assuming your torrc is a text file). Then save this file as batch file in the “startup” folder which should be at C:\ProgramData\Microsoft\*Windows*\Start Menu\Programs\*Startup* *What this does is it creates a script for windows to automatically run at startup that tells the os to point to the directory tor expert bundle is installed in and launch tor.exe and read the configuration file. This is tested and working for me. But I am still trying to write a script to automatically download and install the newest tor version when released as well as obfs4, proving difficult as the url changes with each version. Any thoughts are appreciated, thx very much.* -- --Keifer

1 0

Why MyFamily?
by [REDACTED] 27 Feb '20

27 Feb '20

Last week i got an email with a warning that some of my relays are missing the correct MyFamily setup and that i am a risk to do end-to-end correlation attacks together with a list of all relays i operate plus one relay which uses the same name than i use but is not operated by me. I already knew that not all of my relays have a correct MyFamily setup because as long as i am not sure if they will stay i usually dont include them in MyFamily because it is a pain to edit every torrc if they anyway will disappear again soon. I did it that way with all relays before and when i am sure that the hoster is okay with me and that i am okay with the hoster i always included them in MyFamily. In the received email nothing was written that someone might expect an answer from me so i deleted that email and to not trigger that warning again i deleted the contact info from these specific relays for now. A few days later i got a message that some of my relays will soon get rejected because i did not responded to the previous email. I explained why i do not have a correct MyFamily setup and i explained that one of these relays is not operated by me even if it has the same name than one of my relays. The answer of the bad-relays mailing list was that its important for them to know that one of the relays tried to look like me and that i can use a third-party tool for setting up the MyFamily and that further discussion about the MyFamily is more suitable for the relays mailinglist. What i learned from that: - The bad-relays team expect an answer to their emails even if they do not tell you that in the first email and rather send you a second email that they will soon reject your relays if you dont answer them. - I could do an end-to-end correlation attack (I knew that already and would not use the same name and contact info on my relays if i would like to do that) - It is possible for them to pin relays to specific operators without relying on the contact info or MyFamily entrys (I assume they guess that by looking at the relays names because otherwise they hadn't put a relay which is not operated by me into my warning message) - If setting up the MyFamily option is too painful for you then you can use a third party tool which is not part of the torproject - Relays names are free to choose and double entrys are okay but if someone operates an relay with a name you choosed before then you can report that operator to the bad-relays list because that operator might be malicious (Thankfully my relays are not called "Unnamed") So for what reason do i set the MyFamily option beside making a Hidden Service Guard discovery attack more easy?

6 7

DNSEL (exit relays list) service changes
by Iain Learmonth 27 Feb '20

27 Feb '20

Hi, In order to simplify the operation of the Tor DNS exit list service, which is used to identify if a connection is from a Tor exit relay, I am planning to remove the features that filter by exit policy. We recommend that if you are running an exit relay then you should dedicate an IP address to that and not be using it for other activities. As such, I do not think this is going to affect exit relay operators as exit relays are unlikely to be talking to services that their exit policy does not allow talking to anyway. Still I am asking here to make sure that this change isn't going to have any serious negative effects. Has any operator deliberately excluded anything from their exit policy in order to have TorDNSEL report to service operators that the connection is not from an exit relay? Thanks, Iain.

1 0

Re: [tor-relays] Why MyFamily?
by [REDACTED] 23 Feb '20

23 Feb '20

Hi nusenu Am Fr., 21. Feb. 2020 um 22:24 Uhr schrieb nusenu <nusenu-lists(a)riseup.net>: > Hi [REDACTED], > > > Last week i got an email with a warning that some of my relays are > > missing the correct MyFamily setup and that i am a risk to do > > end-to-end correlation attacks together with a list of all relays i > > operate plus one relay which uses the same name than i use but is not > > operated by me. > > the email [REDACTED] is referring to for the interested readers: [1] > > > I already knew that not all of my relays have a correct MyFamily setup > > because as long as i am not sure if they will stay i usually dont > > include them in MyFamily because it is a pain to edit every torrc > > Yes, manually managing MyFamily is a pain with that many relays. > It is best to automate it so you don't have to worry about it > no matter how long your relays might run. > > It is also relevant to note that we are not talking about fresh relays > (born days or weeks ago) but >6 months. > I think the relay you are talking about is the relay in Yekaterinburg. This relay is not listed as with no MyFamily in the first email but after receiving the first email i decided that i am okay with the newer hoster more than the older hoster so i included the newer one in MyFamily and excluded the older one and will probably let it expire so the relays mentioned with no MyFamily setup in the first and the ones in the second email should be slightly different. But thats not important anyway. I usually wait at least one billing period. Some of my relays are paid for three years in advance which means there might be cases where a relay will be in a state of unknown for three years till i know if they will stay. > > A few days later i got a message that some of my relays will soon get > > rejected because i did not responded to the previous email. > > A more correct version is: some relays were proposed for removal on the > bad-relays@ list > should there not be any reaction by the operator [2]. > > That is something different than informing an operator about an upcoming > removal since > everybody can propose removals and only dir auths can actually vote for > the removal. > Understood. > [2] > For the readers on this list, this is the second mentioned email: > > I'm proposing the removal of the first 5 entries in the following table > (end-to-end correlation risk) > > should there not be any reaction to this email from the operator. > > > > A previous email from 2020-02-15 did not result in a reply so far. > > > > > +---------------------+--------+----------------------+------------------+-------------------+-----------------+---------------------------------------------------+------------------------------------------+ > > | first_seen | member | contact | nickname > | tor_version | IP | as_name > | fingerprint | > > > +---------------------+--------+----------------------+------------------+-------------------+-----------------+---------------------------------------------------+------------------------------------------+ > > | 2020-02-01 18:00:00 | 1 | NULL | angeltest33 > | 0.4.2.6 | 139.99.238.17 | OVH SAS > | 4BF3D299BC500C350868F078749291C766C7AA6F | > > | 2020-01-11 16:00:00 | 1 | NULL | angeltest5test > | 0.4.2.6 | 51.38.147.96 | OVH SAS > | 951307BA74E44A9C9C208B2F134CDA2409944075 | > > | 2019-08-06 11:00:00 | 1 | NULL | angeltest27 > | 0.4.2.6 | 185.173.177.153 | GalaxyStar LLC > | 95C8B9418E74F3FF80E5C3D3AF7F03156FFBBFBE | > > | 2019-08-31 09:00:00 | 1 | NULL | angeltest9 > | 0.2.9.14 | 104.244.76.190 | FranTech Solutions > | F1D5C0F5157D9B24014BE8C7A1D878AEA6843B42 | > > | 2019-11-21 12:00:00 | 1 | NULL | angeltest26test > | 0.4.2.6 | 91.243.50.239 | Petersburg Internet Network ltd. > | F51A927E34662D6005393F2327C870FB0D0D7FE0 | > > > > > - The bad-relays team expect an answer to their emails even if they do > > not tell you that in the first email and rather send you a second > > email that they will soon reject your relays if you dont answer them. > > I think you are confusing the "bad-relays team" with subscribers or people > sending emails to the bad-relays@ list. > If in doubt require the sender to have a @torproject.org address > (unfortunately there is no actual sender address for the bad-relays team > since it is just a mailing list) > The senders name was "tor-bad-relays(a)riseup.net" which looked official to me. Then Georg Koppen "validated" the second email. For the next time i know that i only need to respond to valid emails. > > So for what reason do i set the MyFamily option beside making a Hidden > > Service Guard discovery attack more easy? > > > - risk reduction for tor users > MyFamily declarations allow the tor client software to automatically > detect relay families when creating circuits to > avoid using multiple relays from the same operator in a single circuit. > This should not matter if the operator is not malicious and like i already said an malicious operator will not use the same contact info or relay name. - reducing the risk for tor users that might become victims if some > operator gets compromized (with all its relays) > This is a reason i can understand. Not sure how much that would really help in practice but i can understand it. - transparency > Every relay operator should declare their relay group to allow everybody > to measure their network fraction (Sybil detection). > Should... But i understand this one too. But as long as my family is still a small one with only one exit compared to others i am not a Sybil attack risk and even if i would would i get any special treatment then? - risk reduction for relay operators > MyFamily also provides risk reduction for operators since they are less > valuable as an attack target > if they can not technically be used for e2e correlation attacks > I think this is similar to your first point but i think that should be the operators choice if he want to take steps against this case. - allow the identification of "false-friends" and actual malicious relays > By setting MyFamily you make it easier to detect relays that claim to be > you > since MyFamily requires mutual configuration malicious entities can not > add their relays to your MyFamily. > > This is what happened in your case (which was a mixture of > misconfiguration and actual "false-friends"). Talking about that particular possibly malicious FranTech relay the operator and me set their MyFamily correctly. I did not included it in my family because i am not the operator and he did not tried to include it in my family so relying on MyFamily was useless anyway. I knew about that relay for some while already because i first thought i had accidentially made one of my relays an exit but decided to not report it because relay names are free to choose. Thats the reason why i was so mad about the fact that someone assume this particular malicious relay is operated by me because what the other possibly malicious operator tried to achieve (to look like me) was exactly what happened. I think MyFamily greatly fails in trying to solve a problem and is making life for honest operators more difficult but not for mailicious operators. > > If you are really interested into the MyFamily topic you can find a few > tickets on trac.torproject.org about it > (including arguments against it). > I will look into it. > > > > [1]: > > Hello, > > > > This email wants to make you aware that you are probably putting tor > users > > at risk by not properly setting MyFamily on your tor relays. > > > > If the relays using your contactInfo are not actually yours > > please send an email to bad-relays(a)lists.torproject.org > > so they can be removed from the network for impersonating your > contactInfo. > > > > > https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#torrpi1405g… > > > > Thanks for taking care of this. > > > > > +---------------------+------+------------------+--------+----------------------+-------------------+-----------------+------------------------------------------+ > > | first_seen | exit | nickname | member | contact > | tor_version | IP | fingerprint > | > > > +---------------------+------+------------------+--------+----------------------+-------------------+-----------------+------------------------------------------+ > > | 2018-08-28 21:00:00 | 0 | angeltest2 | 27 | > [REDACTED] | 0.4.4.0-alpha-dev | 5.39.60.243 | > 3B07C500AC17E7B5A1EE616613E104A094AB87F3 | > > | 2018-09-05 17:00:00 | 0 | angeltest7 | 27 | > [REDACTED] | 0.4.2.6 | 37.252.187.111 | > EE4AF632058F0734C1426B1AD689F47445CA2056 | > > | 2018-09-05 20:00:00 | 0 | angeltest8 | 27 | > [REDACTED] | 0.4.2.6 | 185.112.82.50 | > 7AAF5597B18D82CC90CA95FB7976A1CEA4A32E06 | > > | 2018-09-07 23:00:00 | 0 | angeltest9 | 27 | > [REDACTED] | 0.4.2.6 | 92.38.163.21 | > 9288B75B5FF8861EFF32A6BE8825CC38A4F9F8C2 | > > | 2018-09-27 00:00:00 | 0 | angeltest11 | 27 | > [REDACTED] | 0.4.2.6 | 213.183.60.21 | > 39F91959416763AFD34DBEEC05474411B964B2DC | > > | 2018-09-27 19:00:00 | 0 | angeltest12 | 27 | > [REDACTED] | 0.4.2.6 | 91.201.65.91 | > 57C6DF5B93E54EB9C8DB90029D9E9A1111BD34D2 | > > | 2018-12-15 00:00:00 | 0 | angeltest14 | 27 | > [REDACTED] | 0.4.2.6 | 195.123.245.141 | > 465D17C6FC297E3857B5C6F152006A1E212944EA | > > | 2019-01-10 00:00:00 | 0 | angeltest18 | 27 | > [REDACTED] | 0.4.2.6 | 94.140.125.122 | > B517198B86B3859C307857C59F6660A281FC8B47 | > > | 2019-01-10 22:00:00 | 0 | angeltest19 | 27 | > [REDACTED] | 0.4.2.6 | 185.246.152.22 | > A86EC24F5B8B964F67AC7C27CE92842025983274 | > > | 2019-02-26 10:00:00 | 0 | angeltest20 | 27 | > [REDACTED] | 0.4.2.6 | 178.17.170.103 | > ADE6AB2BFBD7A5780B321DC33BBACCD0D777C94D | > > | 2019-04-26 12:00:00 | 0 | angeltest23 | 27 | > [REDACTED] | 0.4.2.6 | 81.169.235.154 | > EFA2E7B073AA4CE2DAF7160F23C90DB805948F4A | > > | 2019-05-29 07:00:00 | 0 | angeltest26 | 27 | > [REDACTED] | 0.4.2.6 | 89.223.100.121 | > 40108FDFA40EDB013F7291F3B4DA3D412ED3A5EF | > > | 2019-08-06 11:00:00 | 0 | angeltest27 | 27 | > [REDACTED] | 0.4.2.6 | 185.173.177.153 | > 95C8B9418E74F3FF80E5C3D3AF7F03156FFBBFBE | > > | 2019-08-13 12:00:00 | 0 | angeltest6 | 27 | > [REDACTED] | 0.4.2.6 | 185.61.149.67 | > 295F1BD8995A12ECC77E050CCF6EC641572739E9 | > > | 2019-08-19 04:00:00 | 0 | angeltest28 | 27 | > [REDACTED] | 0.4.2.6 | 31.207.89.49 | > 1A7A2516A961F2838F7F94786A8811BE82F9CFFE | > > | 2019-09-19 14:00:00 | 0 | angeltest3 | 27 | > [REDACTED] | 0.4.2.6 | 62.141.38.69 | > FF9FC6D130FA26AE3AE8B23688691DC419F0F22E | > > | 2019-10-02 19:00:00 | 0 | angeltest10 | 27 | > [REDACTED] | 0.4.2.6 | 178.254.20.159 | > C1939D36649DE98A202429631D8EFC70128D5F5F | > > | 2019-11-01 05:00:00 | 0 | angeltest5 | 27 | > [REDACTED] | 0.4.2.6 | 51.38.134.104 | > 39C6F833D4B09524770D3655DF825A11213CA0A9 | > > | 2019-11-01 08:00:00 | 0 | angeltest27test | 1 | > [REDACTED] | 0.4.2.6 | 92.223.109.71 | > 1323D34C2FA4AE0EC4EEA9853F3464693EF428E7 | > > | 2019-11-02 14:00:00 | 0 | angeltest17 | 27 | > [REDACTED] | 0.4.2.6 | 5.34.183.29 | > F8AA8D8CCBA0C5F2836DE6315CDFA6E4A31A0890 | > > | 2019-11-05 14:00:00 | 0 | angeltest13 | 27 | > [REDACTED] | 0.4.2.6 | 185.225.17.173 | > A4CC39184AD287D72C2247738835811C7A7ECB8E | > > | 2019-11-21 12:00:00 | 0 | angeltest26test | 1 | > [REDACTED] | 0.4.2.6 | 91.243.50.239 | > F51A927E34662D6005393F2327C870FB0D0D7FE0 | > > | 2019-12-11 22:00:00 | 0 | angeltest29 | 27 | > [REDACTED] | 0.4.2.6 | 87.106.152.102 | > 73283C4DEBC01D3E4A5FD1BB1F2B50D927379F59 | > > | 2019-12-20 04:00:00 | 0 | angeltest24 | 27 | > [REDACTED] | 0.4.2.6 | 2.56.241.243 | > 401A66747713038CEEF6ED28C8AFEB70570EEBCC | > > | 2019-12-20 06:00:00 | 0 | angeltest25 | 27 | > [REDACTED] | 0.4.2.6 | 185.118.164.41 | > C9BC841E180B35F229FD47664F84CF8A8ADB3F68 | > > | 2019-12-24 16:00:00 | 0 | angeltest30 | 27 | > [REDACTED] | 0.4.2.6 | 185.4.135.157 | > B93503D458D9FE97DE5C12D211082871D08F1284 | > > | 2020-01-11 16:00:00 | 0 | angeltest5test | 1 | > [REDACTED] | 0.4.2.6 | 51.38.147.96 | > 951307BA74E44A9C9C208B2F134CDA2409944075 | > > | 2020-01-12 17:00:00 | 0 | angeltest31 | 27 | > [REDACTED] | 0.4.2.6 | 185.101.35.219 | > 2F8B9500DC98C13FD28CC51E47D3416DE423ED78 | > > | 2020-01-14 15:00:00 | 0 | angeltest32 | 27 | > [REDACTED] | 0.4.2.6 | 185.99.2.178 | > 12B1A5769D38FF47CF68C2235E1BDA315DF400F2 | > > | 2020-01-23 04:00:00 | 0 | angeltest16 | 27 | > [REDACTED] | 0.4.4.0-alpha-dev | 195.123.238.164 | > D5812BAB52820A4D448E5F16EE363A0F4CEEF691 | > > | 2020-02-01 18:00:00 | 0 | angeltest33 | 1 | > [REDACTED] | 0.4.2.6 | 139.99.238.17 | > 4BF3D299BC500C350868F078749291C766C7AA6F | > > | 2020-02-11 14:00:00 | 1 | angeltestwindows | 1 | > [REDACTED] | 0.4.2.5 | 91.132.147.168 | > DC81AA3B1D51566DBF27BFA562E4047AEB1C52DA | > > > +---------------------+------+------------------+--------+----------------------+-------------------+-----------------+------------------------------------------+ > > > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

5 10

New relay on dynamic IP address
by Mario Costa 21 Feb '20

21 Feb '20

Hello, I started a new relay at home. I was really surprised to see it gain a Guard flag in about a week since it first came online. My first relay (on a VPS) became a Guard well over a month after I set it up. How can I assess what was different this time? Also, I’m wondering what will happen when the dynamic IP changes. Sooner or later I’ll have a power outage or restart the modem. Last time my IP changed it happened overnight for no evident reason. Will this relay lose its flags? Is a really with a dynamic IP address useful at all? Cheers, -m

7 10

100% CPU load on Windows Server 2019
by [REDACTED] 21 Feb '20

21 Feb '20

Hi, for diversity purposes and curiosity i decided to choose Windows Server 2019 together with TheOnionPack for my first exit relay. But before it even started to process any user traffic the CPU from time to time gets maxed out for several minutes what makes it ugly to operate a relay on Windows. Looks like its this one: https://trac.torproject.org/projects/tor/ticket/24857 Will there be a fix soon or should i rather switch to Linux? Greetz

3 5

unbound statistics interpretation
by Toralf Förster 19 Feb '20

19 Feb '20

Hi, at a system shutdown unbound writes the stats in the syslog. Looking at the stats (pls see below) at a fast relay with 5 days uptime let me wonder about the huge resolving times above the 4 second limit. Especially I do wonder if there's a parameter to tell unbound to stop a resolving attempt -say- after a minute or so? I'd appreciate stats of other relay operators. Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: service stopped (unbound 1.9.6). Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: server stats for thread 0: 1309396 queries, 97671 answers from cache, 1211725 recursions, 0 prefetch, 0 rejected by ip ratelimiting Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: server stats for thread 0: requestlist max 395 avg 7.96712 exceeded 0 jostled 0 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: average recursion processing time 1.439270 sec Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: histogram of recursion processing times Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: [25%]=0.0159959 median[50%]=0.0373616 [75%]=0.103885 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: lower(secs) upper(secs) recursions Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.000000 0.000001 29362 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.000128 0.000256 3 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.000256 0.000512 107 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.000512 0.001024 719 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.001024 0.002048 277 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.002048 0.004096 847 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.004096 0.008192 109419 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.008192 0.016384 170260 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.016384 0.032768 258052 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.032768 0.065536 262585 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.065536 0.131072 131851 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.131072 0.262144 108361 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.262144 0.524288 62805 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 0.524288 1.000000 36220 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 1.000000 2.000000 17353 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 2.000000 4.000000 6835 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 4.000000 8.000000 2753 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 8.000000 16.000000 1845 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 16.000000 32.000000 2985 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 32.000000 64.000000 1773 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 64.000000 128.000000 4811 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 128.000000 256.000000 700 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 256.000000 512.000000 1487 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 512.000000 1024.000000 294 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 1024.000000 2048.000000 3 Feb 19 20:25:04 mr-fox unbound[2006]: [2006:0] info: 2048.000000 4096.000000 6 -- Toralf

1 0

Would you place your secrets or in worst case make your life
by zwiebeln 17 Feb '20

17 Feb '20

depended on a network that is 21 percent controlled by a single person that you don't know? https://nusenu.github.io/OrNetStats/allexitfamilies I think we should start an open debate on that fact, best ending up with giving some recommendations. I am sure that question is relevant to torproject.org as well. Lets start Paul

5 5

Fingerprint is marked rejected
by LeoR 17 Feb '20

17 Feb '20

Dear all, I am running a few Tor relays for more than 100 days. Since last Friday, I am getting the following message on each relay: [warn] http status 400 ("Fingerprint is marked rejected -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to bad-relays(a)lists.torproject.org mentioning your fingerprint(s)?") response from dirserver '171.25.193.9:443'. Please correct. The message above is also reported for other dirservers and prevents my relay for being online (they are all offline currently). I am just running Tor 0.4.2.6; no other activity is performed on any of my relays. I have already contacted the bad-relays list for the first relay offline; afterwards, I realized that all my few relays are off-line after more than 100 days of normal activity. Do you have similar experience? Sincerely, Leo

3 5

Bridge on Raspberry Pi Zero
by skarz 12 Feb '20

12 Feb '20

What is the current support for running Tor on Rasbian, and is running a bridge on a Pi Zero feasible? I vaguely remember there being repository / package / dependency issues with Raspbian last time I tried. Thanks!

5 6

Is This Leap in Bridge Clients Normal
by Eddie 10 Feb '20

10 Feb '20

Hi, For about 6 weeks now, I've been running a couple of obfs4 bridges, one on port 80, the other port 443. Up to yesterday, the port 80 one had seen zero traffic, when this started to be reported: Feb 09 13:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. Feb 09 19:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 533 unique clients. Feb 10 01:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 63 unique clients. Feb 10 07:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 212 unique clients. Feb 10 13:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 93 unique clients. Feb 10 19:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 61 unique clients. Is this kind of sudden usage normal. For the port 443 bridge, I have seen very little traffic at all, which surprises me as I thought that obfs4 bridges on port 443 were highly sought after. A relay search for "OhNoAnother" will pull up the details. Cheers.

2 1

Tor Meetup - Onionspace, Berlin [ February 6th, 6 pm ]
by gus 04 Feb '20

04 Feb '20

Dear Tor friends, This Thursday (February 6th), a Tor meetup will take place at Onionspace in Berlin. Starting at 6 pm, we hope you can join us to talk about the tor network and what we have been working on Tor Project. See you there! cheers, Gus Tor Meetup Berlin ================= When: Thursday, February 6th, 2020 Time: 6 - 7:30 pm Where: Gottschedstrasse 4, Entrance 4, 13357 Berlin (U Nauener Platz) Link: https://blog.torproject.org/tor-meetup-berlin-feb2020

1 0

Re: [tor-relays] Consensus Weight Dropping/Authority Issues?
by starlight.2018q2＠binnacle.cx 02 Feb '20

02 Feb '20

The rating shift experienced by your relays and many others is likely a consequence of the gradual phase-in of the SBWS scanner implementation in place of TorFlow. I for one find SWBS unimpressive. >Hello, > >I have been watching the consensus weight and bandwidth of all of my 50 exit nodes drop consistently over the past few months. I have not made any hardware changes in my data center and actual >customers have not complained about any performance issues. > >Operating systems and Tor version are up to date. I'm dedicating a significant portion of bandwidth to these nodes - 10gbit/sec. > >Am I having issues with the bandwidth authorities? > >I'm growing frustrated with my performance to resources ratio, I should be doing far better than this. > >Please throw ideas at me - open to any ideas. > >Thanks! >John >Quintex Alliance Consulting

3 2

tor version 0.4.0.x reaches end-of-life on 2020-02-02
by nusenu 02 Feb '20

02 Feb '20

tor v0.4.0.x will reach its end-of-life date in under 3 weeks on 2020-02-02. There are currently over 400 relays still using that version. They make up >10% of the tor network's guard capacity and >7% of the exit capacity. List of affected relays: https://metrics.torproject.org/rs.html#search/version:0.4.0. Please update your relays to a supported release. https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… Some relays with a non-empty contact info running tor 0.4.0.x +-----------------+---------------------+------------------------------------------------------------------------+------------------------------------------+ | IP | nickname | contact | fingerprint | +-----------------+---------------------+------------------------------------------------------------------------+------------------------------------------+ | 103.3.62.168 | Harlan | tor-operator(a)throwaway.com | EA4584960E5C815A383B91BD9C03FB489FE686EF | | 104.236.52.16 | pkswitchny | <tor-op AT innolan dot net> | 029E107A59D2B4FEBD06A6115167BD6D048D9C0A | | 104.244.75.143 | BobsHouseLU02 | bobs.house [AT] mail.ru 36j52chsdz962ivcpN1xfPXkJzUr8JaHWg | 5832668C21FF375C6B77A9BEB01E2BFDC7CD9C43 | | 104.244.76.149 | BobsHouseLU03 | bobs.house [AT] mail.ru 36j52chsdz962ivcpN1xfPXkJzUr8JaHWg | C0FB7C7ED8478AE78846B5C5585DD62E162222E1 | | 104.244.76.214 | BobsHouseLU05 | bobs.house [AT] mail.ru 36j52chsdz962ivcpN1xfPXkJzUr8JaHWg | 65F56DD25EB283238BF6A10C10A8C50D7D83B931 | | 104.244.79.77 | BobsHouseLU01 | bobs.house [AT] mail.ru 36j52chsdz962ivcpN1xfPXkJzUr8JaHWg | 52952860B81079DE731062216F0443DB89C14790 | | 108.39.229.147 | Hermes | Random Person <tor-trouble AT boldandbusted dot com> | 09F64E00F34C88F604163F24D37BEAF9245702EA | | 109.24.234.220 | OdessaState | dlv36(a)live.fr | 04D892C23D4B26D55B2669A3A7E6C67C8817172B | | 109.248.43.30 | KrakowOnion1 | Krakow.pw <admin AT krakow dot pw> | 888812D52446DA7741DEFDB2BA72D5C172A68503 | | 116.203.88.24 | neurostar | Random Person <nobody AT example dot com> | 2A621A40FF3081F612946FDFB8DC781BCE859A05 | | 116.203.93.236 | neurodump | Random Person <nobody AT example dot com> | 6A2676DACAFDBD00C5B94BD343690957A12BB758 | | 129.233.217.29 | Bob | tor_bob AT protonmail.com | F528631C99C0E5525B15757DAED32C8D24FD9326 | | 136.243.69.243 | l3v3lup | 1Jwjq2AGPua8urdfZXtSbEQCKBQWF34qew ronstorabuse[a]protonmail-ch | 64E257D94E739278D5954CC820C9D7EAC4E7A7B7 | | 136.37.102.111 | Unnamed | <tor-admin AT tma-0 DOT net> | 9781B0EE81E95941073AFA37542B36ED71018D49 | | 139.99.194.157 | Tor4tuequeeg | tor4(a)example.org | 86FA023C676A53637A38FCC78A10D73B4A79803B | | 139.99.98.191 | Perceval | florentin aatt rochet ddoott be; LTC: LhRqJZu6U87BJNSUbkACHzVQsK39hJ3s | B22228717E3EA0FBAC5DE92C205F85A9D68E5D70 | | 140.136.150.68 | fjutor01 | roy(at)nisra(dot)net [tor-relay.co] | 3071C6A5AF0C4EF796D9ADBCB7B7989691010A97 | | 141.255.162.34 | darksoul01 | darksoul01 | FE9733F8403BA4215222B9C4CBE9386EE849732C | | 141.255.162.35 | darksoul02 | darksoul02 | 7743A57C42B851FA495D4F26B5B4CA924A3F673E | | 141.255.162.36 | darksoul03 | darksoul03 | 15E0D9A6BCD9247D49CB0D2E26DEC09AD48BC55C | | 141.255.162.38 | darksoul04 | darksoul04 | B2A94B66004A80B6F56B7B30A1FE6993EABB54B8 | | 141.255.166.150 | doutreval | visualbasic033(a)gmail.com | CB4EBE9C475A60A5F2CDA92C83CE093BD945D940 | | 143.106.73.35 | cebolitos | ENIGMA <enigmaunicamp AT tutanota dot com> | 1E7BDE03151AAB779CB4AFEAEEA52536FFAA9400 | | 144.217.80.80 | Elias | florentin aatt rochet ddoott be; LTC: LhRqJZu6U87BJNSUbkACHzVQsK39hJ3s | A61B56A50D13DC29DBB23C6A033FA3F0C57420CF | | 144.76.57.183 | jeremycorbin | jorge <spielman2(a)gmx.de> | 638D91FC9EF661348A6994D04C3499BC03F50BBE | | 145.239.72.73 | aerona | 0x0483E5F4 cyllos <contact AT cyllos dot me> | 01E79D11DAF1B2F522CED15F3304C37656F98C7E | | 145.239.91.37 | Dagonet | florentin aatt rochet ddoott be; LTC: LhRqJZu6U87BJNSUbkACHzVQsK39hJ3s | 96D4C61DB5B38EC7ABE3DB9BB87A97A8587B8087 | | 147.12.234.93 | bigflamingo | Random Person <churchestcATgmail dot com> | E727DFCED859D0ECC914E75185D90BFB09E9555E | | 147.135.36.62 | 1chandotus | Trevor Slocum <tslocum+tor @ !removeme! gmail !deleteme! .com> | 7DB8443AE29FBC450D34E55FA914F42BF929EE49 | | 147.135.78.157 | FissionEx1 | Kevin Hicks <admin(a)fissionrelays.net> | ECB24A326D382F84B7BD630CFDBE1A0CDCE0245A | | 149.154.157.80 | WooptThereItIs | do not contact | A7F80AB7E04C0004E8DE0A0037F8ED54292458BF | | 149.20.176.27 | xorcerynetwin | admin-at-xorcery-dot-net | E462175FB91997EFC58B2C77EA87B7982C2275E8 | | 157.245.231.133 | RebutteNYC | Rebutte Sysadmins <relays AT rebutte dot today> | 835A14E755F2C36292BCDC3897DDD2BA61A8FC13 | | 158.69.63.54 | FissionEx2 | Kevin Hicks <admin(a)fissionrelays.net> | 460E5B882770C19761BC5747541913DB2AD01E35 | | 159.69.207.20 | FissionEx3 | Kevin Hicks <admin(a)fissionrelays.net> | 4FDDFAD51B24DDABB62FB59071F4DC421E76C685 | | 163.172.142.92 | znxpar01 | 4096R/5819E33F Zhongfu Li <tor at zhongfu dot li> | 2E72EEABE4EE19183BEFAA10D88B3C16829C9F99 | | 163.172.195.36 | Nozel12 | mail[at]nozel[.]org | 192BE1B050651A989583FEA7B6B741FD6B3BACF2 | | 163.172.195.36 | Nozel13 | mail[at]nozel[.]org | A20CEA50D70FF39BCDC0EDF8DCEDDE0227876C32 | | 163.172.25.118 | torpidsFRonline4 | torpids AT yahoo dot com - 1JYHfzVFVD7n2Sezz3DEHDFgGYjQWpDjqF | 0CF8F3E6590F45D50B70F2F7DA6605ECA6CD408F | | 163.172.69.166 | OoliidaiNgah | A43AED4A53F50B846EB7509549DC6A732912A5F3 <tor A_T dmesg.site> | ADB398B7F5AC2D936A8080758607F5CCB4B78F3E | | 163.172.85.155 | Edouardine | 0xD2070CB6 admin<at>ajanvier<dot>fr | 3AF8390D3F4B8103DA297CFD514B35740781B87D | | 163.172.94.144 | Unnamed | Random Person <mm266 AT 0box dot eu> | 576989D05B62C05F92EC8405B8B6B19F2AA34221 | | 163.172.95.132 | Nessie | phozon(a)protonmail.com | 94D755B1E9ED1E2A87B8BD5AB7767FB2791AE221 | | 171.25.193.20 | DFRI0 | DFRI <tor AT dfri dot se> - 1Muz37TfXVBiJKRJkAqTNo7MnEZN8hhmJQ | DD8BD7307017407FCC36F8D04A688F74A0774C02 | | 171.25.193.25 | DFRI5 | DFRI <tor AT dfri dot se> - 1Muz37TfXVBiJKRJkAqTNo7MnEZN8hhmJQ | 185663B7C12777F052B2C2D23D7A239D8DA88A0F | | 171.25.193.77 | DFRI1 | DFRI <tor AT dfri dot se> - 1Muz37TfXVBiJKRJkAqTNo7MnEZN8hhmJQ | A10C4F666D27364036B562823E5830BC448E046A | | 171.25.193.78 | DFRI4 | DFRI <tor AT dfri dot se> - 1Muz37TfXVBiJKRJkAqTNo7MnEZN8hhmJQ | A478E421F83194C114F41E94F95999672AED51FE | | 172.104.49.140 | rortor3 | rortor(a)rorvick.com | 8D62C3DC2AADE43324329A5F5FFD97710234DD0B | | 173.249.2.224 | doofenschmirtz | halloanjedendenichkenne(a)gmail.com | 10231E08F19C03D5A2FE3AAD03D863ABDE2081BC | | 173.255.205.113 | rortor2 | rortor(a)rorvick.com | F004C51B7C3136D7DFC20469AA5329B8372A263A | | 176.38.157.38 | WalkAway | gogle mail | 9938E3AAC64CE9D56B743ECD8B2CA235AFB9DF74 | | 176.53.90.26 | FlappyBird | DuckSounds31(a)aol.com | B00478C4CD2F3ACC7D6F02AF8033D2906673651F | | 176.9.1.98 | brooke | email: torchat(a)gmx.net | F5F4019509109A07E90C45A022CEED9ECA1643C8 | | 176.9.114.252 | ne0 | fredreic(at)tutanota(dot)com | 221546DAE86B003139B13BD6F6AE1B4B42B59DF8 | | 178.17.170.116 | 0x616e6f6e | Anon g774i12a2(a)protonmail.com | 0020D8A204A81FC8C8A1D79E2324621705DE4F2F | | 178.17.170.88 | 0x616e6f6e | Anon g774i12a2(a)protonmail.com | BCE2851120595E76E31645633F5FF4771D2097BD | | 178.17.174.14 | TorExitMoldova | potlatch protonmail com | B06F093A3D4DFAD3E923F4F28A74901BD4F74EB1 | | 178.17.174.196 | Leodagan | florentin aatt rochet ddoott be; LTC: LhRqJZu6U87BJNSUbkACHzVQsK39hJ3s | 255CF8CC68137449DEBD443797AB3D851E3065B2 | | 178.254.7.88 | wr3ck3d0ni0n01 | torrelays A-T cyb3rwr3ck D-O-T net | 85A885433E50B1874F11CEC9BE98451E24660976 | | 178.79.165.21 | sexrobot | SexWarrior <tor(a)omgomg.eu> | 51C0ACFE82D5491640645F9544FA370203ACF1D6 | | 179.43.134.154 | father | father | 05ACE592DA42E82DA94494F17DCA2023BB0267CB | | 179.43.134.155 | energy | energy | D9634C3C4C15985C7C2CF999890DEF934B059277 | | 179.43.134.156 | dream | dream | 603EF1DBF0ADE010E8340F78E44447B324EB9AFB | | 179.43.134.157 | lumos | lumos | 0FA4A101490BAE59BFB09ADF41E4FAB290C88CFA | | 184.153.12.141 | 1country2systems | <arguspanopte AT protonmail> | 78B7D242CDA1EFC577A9891DD9A1C66BC71C8978 | | 185.100.85.101 | TorExitRomania | potlatch protonmail com | 4061C553CA88021B8302F0814365070AAE617270 | | 185.100.85.61 | nibbana | Andrew Deason <adeason+tor AT dson dot org> | 025B66CEBC070FCB0519D206CF0CF4965C20C96E | | 185.18.176.226 | accidental | Anonymous Person <tor AT linuz dot cf> | 3BB71BAB173DBB4FB24B90843DBD50D8F70406EA | | 185.191.204.254 | DuckYou | DuckSounds31(a)aol.com | AF4997738E0CFC014CD04FB09A670D2C5F1E79A4 | | 185.198.26.149 | portnoy | Contact Person <treebark 9999999 AT gmail dot com> | 0A0C01DD0044E70318D9E3DA5F125A09069C57C1 | | 185.2.31.8 | cx10TorServer | info(a)durukanbal.com | 96B358744E1DB0D6DBB96D32C27F91E9F695275E | | 185.207.139.2 | reactortornode | Tor Reactor <0d0[AT]protonmail.com> | u42omsvzmh7momdk.onion | BTC:13 | DD808ECE4F2E24F377CBE11E335ECDA196FE3B78 | | 185.21.100.50 | SamAAdams2 | email:info[]sebastianboegl.de operatorurl:https://sebastianboegl.de gp | 58ED9C9C35E433EE58764D62892B4FFD518A3CD0 | | 185.34.33.2 | lqdn | 4096R/34650013 La Quadrature du Net <tor(a)laquadrature.net> | 74B5CA13B3295C161838F4016A1CE0A49BE8894D | | 188.114.140.245 | tor0kryptonit | dev.null(a)kryptonit.org - 1AjBZw8ExjkWgh7Y5s9mLX4UXHadzPfKQu | 91041B34A0B91759475B2CEC0AB3063FF23C758D | | 188.166.20.124 | python273 | 0xB8A168B3A02C01E3 <tor AT python273 dot pw> | 9A0EC53705088AF0EB2941524E17E8AC6116C490 | | 188.214.129.21 | partain | do not contact | 0F52E9652F96AD1D500AC062350A149902C128B9 | | 188.244.43.25 | a6xzL5 | Ivan <ivan(a)prokudin.org> | 5D9622326D1AE40F2F4D570BE1C7FC7505F3528C | | 188.25.165.120 | d3xtor | dexter(a)d3xt3r01.tk | 506763994792208999529D03C016774C814386A8 | | 188.68.46.164 | ncbanerelay | <tor AT b4ne dot de> | BFC1305C8B37E5161C2E37135DF2D4E53CC38ACE | | 188.68.53.92 | schattenbahnhof1 | <tor-operator [-at-] tec.link38.eu> | 5AC46D393C7E1FB0DF7F3424737239A27F9586C9 | | 188.68.53.92 | schattenbahnhof2 | <tor-operator [-at-] tec.link38.eu> | CCCB01941013A05D2A9A3A5926C9011B427A1896 | | 192.42.113.102 | Spigen | Gijs Rijnders (tor AT ip-eend DOT nl) | 874D84382C892F3F61CC9E106BF08843DE0B865A | | 192.42.115.101 | cry | Gijs Rijnders (tor AT ip-eend DOT nl) | B204DE75B37064EF6A4C6BAF955C5724578D0B32 | | 192.42.115.102 | Onyx | Gijs Rijnders (tor AT ip-eend DOT nl) | 6DFEB41C04CCE846871338E85DD5ACF5CFB6C1DD | | 192.99.71.91 | pylonl | SHA256 {00354174cbb1e3af3a1889d464daf7c783478f9cfca372c795172cd21d740a | 67352C511711E162CE1EBCF9212D72B51BC4FA7A | | 195.154.107.12 | fujiwara | tor(a)govanify.com | 43FF3346A3F8E4ED27F631DC956C4CD8D6173D7A | | 195.154.161.5 | lapin | ruhtra.mar(a)gmail.com | 25E078CD1E537A7418318168F7E1990EF2A160C8 | | 195.251.252.226 | AUEBTor | Random Person <abl.spam AT gmail d0t com> | 457D6035A953805B82D2A9933EDE3A0EA4B675FE | | 198.100.145.207 | AaronKSQC1 | Aaron Kwei <aaronkwei(a)protonmail.ch> | D8B16FB9CDFF228C03B1A628B3B45620F93E320A | | 200.122.181.78 | Splinter | ninja.turtle5(a)aol.com | D95980C15F79E094AE255BA8F1B57FD6C81F2B54 | | 200.194.38.246 | mitchell | jacobo(a)jacobo.org | 40FCA00B9ABF25E88BDF739108D199373F84F3F5 | | 206.192.252.123 | luxurywood | LuxuryWood <luxurywood at safetymail.info> | AB3227DB470B17883D24D830EA84EBFBDC7D5815 | | 209.126.101.29 | NoisePollution | tor(a)diiv.com | 42645860028723FD57B5694E74C38C956E3476BE | | 209.148.46.83 | csgeorgetown1 | Micah Sherr <msherr(a)cs.georgetown.edu> | D80A50EF9BFD77CFCEA5326F389E24F932D6F9DA | | 209.182.239.70 | depwnparty | tor theatsign pwn party | F6DD00F277B741E4F4A216532476D8476B98D96C | | 212.47.254.236 | torpidsFRonline1 | torpids AT yahoo dot com - 1JYHfzVFVD7n2Sezz3DEHDFgGYjQWpDjqF | C91102131E6B9CECFC56C4A29ADA4E638D7872F7 | | 213.108.105.71 | JongeDemocraten | <tor AT jd dot nl> | 69620419A3D0077272B2EA3952A1F46880FDFAE5 | | 216.218.134.12 | Unnamed | 0x3C68C8DBCBA783EF Joel R. Voss <jvoss at altsci dot com> | 040A7442349A2AC92233C2470D6C4F2BD02EDF15 | | 217.170.205.107 | HobGoblin | abuse(a)maytownsend.is < abuse AT maytownsend dot is> | 5D96F61FED26C299093B4B0409ED3A18765A6DB2 | | 24.151.1.51 | duat | Duat Tor <duattor AT gmx dot com> | 5835654384EA7DB06B2581A3999730F15E51922F | | 27.33.99.229 | Unnamed | djrodgerspryor+tor(a)gmail.com | F0A011B893002130A2340EF19252E0850899736B | | 37.120.169.252 | DrNefarius | tor(a)grunix.de | 7B2FD4FFD565993CB4C4334AC0A0C42985EBEADB | | 37.123.166.244 | fak3Relay | fak3(a)tuta.io | D7829A21726220AF77401BE5B2B132963A0BE82B | | 37.153.16.170 | GeorgeIV | tilirim(a)gmail.com | 6CAD6AB6CCCB580AB345B2D789736B80E9AA02F4 | | 37.252.187.129 | 1d1dchang3th3c0nf1g | Random Person sexyhexi(at)outlook(dot)at | 79B207AD51842FA215D956B9307B3D01CD347368 | | 45.14.148.96 | BobsHouseRO04 | bobs.house [AT] mail.ru 36j52chsdz962ivcpN1xfPXkJzUr8JaHWg | B1BF289B965760D17B3508E3E48FF5DC8154FB70 | | 45.14.148.97 | BobsHouseRO05 | bobs.house [AT] mail.ru 36j52chsdz962ivcpN1xfPXkJzUr8JaHWg | 8574D4F76F44EBD2A274DA94732BD5791C08675B | | 45.14.148.98 | BobsHouseRO06 | bobs.house [AT] mail.ru 36j52chsdz962ivcpN1xfPXkJzUr8JaHWg | 1F226CD8277DA2C28D15364E88D596F9FCCED98B | | 45.154.255.44 | TORKeFFORG | KeFF NOC <noc AT keff dot org> | 1DFB1135088658EE9D4D9B272BE15E26176AD052 | | 45.55.121.222 | dreggle | Joe Rutkowski <joe plus tor ayt dreggle daht cahm> | 8E2B95CDF87B43B6BDF2A2FCE303B7E1AA429CC4 | | 46.105.121.228 | notani2pnode | Theo Thomann - t_thomann1974(a)gmx.de | 0D99F89BBB92BF5557F8D3F895DB218A72871089 | | 46.246.37.231 | Somone | Someone at example dot com | CD406A3CBCF313B0B068690CC706C142484CE29C | | 46.28.207.107 | behrmann | <Jannis> jannisde85(a)eclipso.eu | C2C2B839F4CFFA5F7B7A40CB0BE84F7D948CB510 | | 46.4.122.173 | chaoxrelay | jens <jens(a)chaox.net> - 11XxuJRkNp3CrxwP6DGdHwEa6UjZnpckp | 1099983E2C5C3ECDAD0B7D5AABD2AC6BF2CBBF70 | | 46.4.55.177 | brotherjacob | Ins0mnia Shells <orwell1984.info AT gmail dot com> | 6F6586F1631CAC1115B9561656E7664D386B7F4B | | 49.50.107.221 | newsvendor | DuckSounds31(a)aol.com | 061370AE41C1084B2910EB0522C8B2DB1C2CB96E | | 5.146.25.246 | J0nxy | J0nxy(a)web.de | 8DABF042892435C9BD2DAEAC676F6BBB5018FF18 | | 5.44.101.190 | Freebird33 | Felix <zwiebel ta quantentunnel tod de> | 73A5A81688BD536BFBABE18630F5BD6306C9AC8E | | 5.9.120.250 | SomeStudentsServer | some student <ufrbc AT student dot kit dot edu> | 489606DA64FD4B68A76C49386298695E6C30B5E2 | | 5.9.98.43 | ifigenia | <Jannis> jannisde85(a)eclipso.eu | F6CD4DBF5850AC4386DD9A424918AD3C6BA2716F | | 51.15.115.217 | Atomsk | tor-atomsk(a)protonmail.com | D381355B16643759752B6FA37EF97EA8BDC6F3D8 | | 51.15.249.81 | UenoStation54 | tor(a)ueno.red | 235D3444236ABC28F412E93814F6B783200D4630 | | 51.15.252.175 | Torstrasse | tor.leak(a)spamgourmet.com | 3D8794DF11C97D173DACA8BD24F9C509D2FE0B70 | | 51.15.36.229 | torpidsNLonline1 | torpids AT yahoo dot com - 1JYHfzVFVD7n2Sezz3DEHDFgGYjQWpDjqF | 7B68E4C2601B77B5B4313E3FCB34FD9DC8886030 | | 51.15.75.80 | MolInstance02 | tor(a)moletrix.be | 1EE7CF61BD374F65606C878E8ADF0DCD8A660FC6 | | 51.15.75.80 | MolInstance01 | tor(a)moletrix.be | 1F8EC2627C544E05B5EE32E1A6AB787DB879C44E | | 51.178.16.72 | Tor4uidiepug | tor4(a)example.org | D41AFF22CF75B594E2CFEB37DF844DBEDECA478D | | 51.254.220.21 | sexwarriorHQ | SexWarrior <tor(a)omgomg.eu> | 8C63F68259DC7FDA9E49B567E74D0C831FE183A9 | | 51.255.26.152 | Fission3 | Kevin Hicks <admin(a)fissionrelays.net> | 71539D1911ECB826069A4D156771AC4F9F4632A7 | | 51.255.26.153 | Fission4 | Kevin Hicks <admin(a)fissionrelays.net> | 91E7CA6B8D0AAD77C7CFB8FEA25BF4F46DA1042A | | 51.255.26.154 | Fission5 | Kevin Hicks <admin(a)fissionrelays.net> | 5D765770B4DB110D88787457978AB4008CF65CAC | | 51.255.26.155 | Fission6 | Kevin Hicks <admin(a)fissionrelays.net> | 53134D9637D9FBE565FA1E3AF82B23CC964C56D6 | | 51.68.187.152 | Fission7 | Kevin Hicks <admin(a)fissionrelays.net> | 98138DFD3E2C8C89D8F5AB11EF9B6BFF272D83B4 | | 51.68.214.45 | SumomoRelay | tor-operator(a)eye.bz | 395CEC4F978857B1169DA78CF1208FD13B715FD0 | | 51.75.86.103 | Fission8 | Kevin Hicks <admin(a)fissionrelays.net> | 438DC9B6B5C5375D332BB338D7E5C1B9EF448960 | | 51.77.72.200 | Fission9 | Kevin Hicks <admin(a)fissionrelays.net> | 929BB84A68198CE35E2F2828812840AF5C2CBC4A | | 51.89.139.63 | Maquis196 | maquis196(a)gmail.com < maquis196 AT gmail dot com> | 82F383EF7BAED03B03E4CEAB0EE8E5208629DC41 | | 54.37.16.241 | Merlin | florentin aatt rochet ddoott be; LTC: LhRqJZu6U87BJNSUbkACHzVQsK39hJ3s | 091BB38D8A641014A652A36A8827A9E30EEEA882 | | 62.210.107.208 | Unnamed | Random Person <nobody AT example dot com> | 520AD8D6FD09CF4B8CB456BFBD2BF1F1DF8EAA45 | | 62.210.148.97 | texthtml | tor(a)texthtml.net | 2D531C17827E0054DF612F26EEAAE51220CFE799 | | 62.210.149.16 | wsantos | william.santos(a)hotmail.co.uk | 8990AEA919ACBC16E69D5BC616A29F8F82A5E27A | | 64.113.32.29 | Libero | Network Operations <tor(a)t-3.net> | 30C19B81981F450C402306E2E7CFB6C3F79CB6B2 | | 64.237.51.46 | KuroNeko | cstdenis <cstdenis AT ctgameinfo dot com> | 95C4EF3787069A3A1A3B5FD4057A34CA97C171C3 | | 66.23.227.135 | FissionEx4 | Kevin Hicks <admin(a)fissionrelays.net> | 3B4C5729F829CA2E895B81AF834A63DB336D0FFE | | 66.70.222.240 | torcow2 | <jeff(a)mulb.us> | 31DDF87B0464C8AA3715F9AC93E8A619E60E5031 | | 67.249.138.113 | Eutaxy | franklin at eutaxy dot net | 2377F415AC24BC6CE01C1E00E1F5E850AF28402D | | 67.4.195.22 | ArguteTor | tor(a)argute.io | 51826F7C88BD7BFF3B31E0C01C44F7821DF673D3 | | 69.159.158.89 | TorqueQC | reaper at imap dot cc | BE5D14F0077E7CA33C9C8D357A8C9E5F18FB2F90 | | 70.31.41.162 | PixlPowerPC | Seshan Ravikumar <https://seshan.xyz or http://7snfudlzbmo35hxn.onion/ | 62A669CF65412F36D5E815DB35FDF2A8C8C673F9 | | 75.154.232.57 | Acrolepiopsis | Eric Schewe <tor AT pickysysadmin dot ca> | 32B1913ADEAB0EC6D87516995D755D7D5A44FE56 | | 77.3.98.58 | Unnamed | Nym <tor.20.sokrat AT spamgourmet.com> 1JH2RueDoXvEaNEdQKByW3mj1C3HquW | A36A198D2E091C99829CAA889F063AC956769317 | | 77.37.218.221 | Koshaq | me(a)koshaq.net | DFF7791B90883AB66895472B7871D0A224F064F8 | | 77.58.250.110 | covfefe | Mirco Verona - mircoverona(a)protonmail.ch | BF7A29C67B0502CF3082B1332BBFBCABAAC550D5 | | 78.46.217.214 | torpidsDEhetzner1 | torpids AT yahoo dot com - 1JYHfzVFVD7n2Sezz3DEHDFgGYjQWpDjqF | 9E1E4F5B5F94812D02C4D18CB4086CE71CA5C614 | | 78.46.63.113 | TommysTorServer | 211CA2D4/2281 885D DB14 376A 2882 BCDF C053 30B3 211C A2D4 Thomas <to | BF2EA78E4F02CC521E6785A8EC41694042C887CC | | 78.47.134.196 | Desperado | Admin <admin AT tor-relay dot io> | A13281DBD8F8E484E95DD273B3EE7FC14C1B0A7A | | 78.88.252.121 | NervousPayne001 | Random Person <nobody AT example dot com> | 18FBAE75066076015C9272EE8C7FA3DDF5574CE1 | | 78.94.186.133 | raveena9001 | freitag381(a)gmail.com | EF11B59704051BD6A97D385E10710488FA1D800E | | 79.172.193.32 | fuckmedeepintheass | Random Person <nobody AT example dot com> | 01D82BBB77BC00511F0CB1A10DE4318A8ACA7E40 | | 80.211.211.72 | nfsvks | nfsvks at gmail.com | E855AF7BA953B6581781B87E90B8D0D31680E14C | | 80.241.60.207 | mailboxorg | 0x18A24864 mailbox.org support team <support AT mailbox.org> | 85D4088148B1A6954C9BFFFCA010E85E0AA88FF0 | | 80.253.92.71 | Garados | garadosgen2(a)protonmail.com | D8837125F99559B5385B4A09DD7007951DD17B92 | | 80.253.94.252 | recklessbolter | 512(a)gmx.ch [tor-relay.co] | 672A56A583C658372E63ACEB43E7F791C2819548 | | 81.169.167.121 | Tor4ahchaino | tor4(a)example.org | C0D1D22D41CD6C397E905B95A9B4BD348E8DD2AB | | 81.17.27.130 | matrix | matrix | 2C29E0D35265162B6838F99A7D8D94B7AAE6EA2A | | 81.17.27.131 | lucky | lucky | EAC5D96E267F49FBB8E21BE23176B4830EC8DA1F | | 81.17.27.132 | cosmos | cosmos | B848895C9A51C88C972FE4D69E38D37D25088717 | | 81.17.27.133 | butler | butler | B3982C0DD60DB1531AFD43A58EA37166555FBD3A | | 81.17.27.134 | discovery | discovery | BBBF0D0023880786A702E3D4E247F258D2AB3E34 | | 81.17.27.135 | zen | zen | 205FE0514BC901E8B8589D369F6DB96E080A9BBC | | 81.17.27.136 | spark | spark | 9B9C0E80DCD8ED9A2549847C7736FF999AE8B4AF | | 81.17.27.137 | holmes | holmes | 5B4678104F0CEE0679DEBAFE175509A9D1EF060B | | 81.17.27.138 | dock | dock | A22A79C44E94A7A1D2FA838779EA8AFF91F894AD | | 81.17.27.139 | machina | machina | 7BD7B547676257EF147F5D5B7A5B15F840F4B579 | | 81.17.27.140 | mage | mage | 20F7A06BB6DC5A2B9EADABDC694D30AF1A9A7C68 | | 81.17.27.141 | guard | guard | 654BEAD8ACDB5DBB8856174EF246E958F5CE93FB | | 81.182.118.240 | km6p31yo | 0xB2D839CE km6p31yo <km6p31yo AT danwin1210 dot me> Donations:bc1q6m45 | 7FD6C9AB839761B3334BC9BA8E8543261B93BB88 | | 82.103.140.87 | arnall | <Jannis> jannisde85(a)eclipso.eu | A1B7C1F83E5DA4376FD2E1DBA7AC28A71AB332AD | | 82.165.70.65 | zwiebelringXX | zwiebelring_LA(a)trashmail.com | DA4B488C2826DFBBD04D635DA1E71A2BA5B20747 | | 82.169.130.61 | Hijnn | stfn(a)hijnn.net | F5746F6257DFE87E3A90753C2A0439926C55552F | | 82.223.17.164 | lolMordekaiser | ctci(a)fastimap.com | 51142A1DF64451C7750ECB85788364A68A07CEC2 | | 82.4.8.138 | TubularRelayPiersGB | <johnyd adt firemail dooit cc> | 858BEC79D7355EC0631E98D47CF14B576BFD6D0F | | 82.95.107.51 | LxcTorNode | torcontact AT xs4all DOT nl | E1EEAA9167B40A367D9AB43033648800E9AE2E74 | | 84.87.37.162 | avdrelay | avdrelay(at)yopmail(dot)com [tor-relay.co] | A4B81B36AAEF89252A054EB1834FEAFBC8165200 | | 85.235.250.88 | TykRelay01 | Thomas Steen Rasmussen / Tykling <thomas(a)gibfest.dk> (PGP: 0x772FF77F0 | 72B2B12A3F60408BDBC98C6DF53988D3A0B3F0EE | | 87.117.247.110 | 66726565646F6D | rimsalot(a)mail.ru | 4BA58DAC7296A43835C4C274A32731FF1C1F8A80 | | 87.236.212.128 | ImReallySorryJohn | JustARatherGuy(a)protonmail.com | BE4A328744F48162D8A0029B10E1B7F5639877B3 | | 87.79.95.151 | scattystorrelay | 0xD05024C7 Bjoern Guth <scatty(a)bguth.de> | 71CA3DA87137DC8DB307FAD0B39C8401D6E3EF0E | | 88.152.84.75 | ViDiBox | <ben + tor [at] graef . in> 128qLZCaGdoWhBTfaS7rytpbvG4mNTyAQm | 3A8836B2549C55BD62B2137D14B743EEA4EC0444 | | 88.198.128.218 | TykRelay04 | Thomas Steen Rasmussen / Tykling <thomas(a)gibfest.dk> (PGP: 0x772FF77F0 | 3DCA95587F917F3F212B598731B97BDB85BFEE92 | | 89.233.43.74 | TykRelay03 | Thomas Steen Rasmussen / Tykling <thomas(a)gibfest.dk> (PGP: 0x772FF77F0 | 872B18761953254914F77C71846E8A2623C52591 | | 89.36.218.127 | ddgserut | ddgserut(a)gmail.com | B764C8F659C471408A404067ADB562AF8C8E89B8 | | 91.121.82.132 | Hack2G2 | contact<at>hack2g2<dot>fr | 87D28EE0C993B250EF93DBE4D2CB0E30244D757C | | 91.219.238.148 | ZedIsDead | 0x8BDC87FB7215E189 | 568E434F725B7828D17EF2B33C2F5CC84F18FCE3 | | 92.243.0.179 | sybaze | aze <aze AT anonsbh dot co> | C9B68C802CA20C3E4FA46D77153D6EDC80F13CF5 | | 94.16.116.137 | clicker1 | <tor-operator [-at-] tec.link38.eu> | 0AC4C4D8BCA8DA7BAE6BE3FEA87442E724353CBF | | 94.16.116.137 | clicker2 | <tor-operator [-at-] tec.link38.eu> | 1A48CACC30FC06427103CEB38C4132873187E7DB | | 95.154.221.176 | privproquo | BTC: 1LduDraJ4fWRC2wMYkx8hLb8LD1oCMxRoC {poorvictim [aet] getbackinthe | 9DE03094BB54F8C1755FE2D58339C78FAFB6AC1E | | 95.154.221.85 | kingCowman | Pwnstr<buffer0verflow(a)tutanota.com> | E82A104746BAC08B617ED949AFEB38F8743C0708 | | 95.216.137.135 | torpidsFIhetzner1 | torpids AT yahoo dot com - 1JYHfzVFVD7n2Sezz3DEHDFgGYjQWpDjqF | 3A27CC4147062E4EFDF46F848FEA7FF032A04E5F | | 95.216.144.113 | hittibuumi | notify(a)jonossaseuraava.eu | F58DB7D175AE3192411CBE3EA9E92632ECEFBC85 | | 95.216.197.155 | Torrot01 | tor+torrot01(a)tzu.io | 58BC63142C881F88D08E071DEB63DBA09DE62141 | | 96.126.125.187 | Infincia1 | tor(a)infincia.com | E254FA3A1E04C96C13ADA297DCD9BB03DE8B1971 | | 96.65.68.193 | stellaranomaly | Admin <TOR AT tritonbase DOT com> | 51374C8DA459C67329FFD5C7502CCAE4194910CC | | 96.66.15.147 | TLCOnion | tor(a)centerfortlc.com [tor-relay.co] 14kmchJcCVVEor1MVSXzfYUL8VQ5JqR9VM | 03A33C3454FC0F9AC6966F12FA486999F5A22896 | | 97.107.132.24 | rortor1 | rortor(a)rorvick.com | 8FF24DC61EA335CAFDD5699A937AD96D594E5904 | | 97.107.139.108 | rittervg | Tom Ritter <tom(a)ritter.vg> | C0EDB08D7540D1DD3CA69809ED17D979F51B66E3 | | 99.124.159.167 | Tor4gaitheis | tor4(a)example.org | 2A5DC4F4FB289D9D3646EBF85642BA4D632785AF | +-----------------+---------------------+------------------------------------------------------------------------+------------------------------------------+ -- https://mastodon.social/@nusenu

3 4

How do I get the *current* Tor exit node IP address over the control port?
by Mike 30 Jan '20

30 Jan '20

Hello, How do I get the external IP address of the current Tor exit node (the one which is in use) without using external services/websites (through curl or otherwise) but only through the Tor control port functionality (using bash or python3). *I have also asked on https://stackoverflow.com/q/59923289

3 5

Relay's Bandwidth
by Tor Developer 29 Jan '20

29 Jan '20

2 1

Trying to write a script to auto update tor expert bundle on Windows 10
by Keifer Bly 27 Jan '20

27 Jan '20

3 4

Re: [tor-relays] New relay on dynamic IP address
by John Csuti 27 Jan '20

27 Jan '20

The stable flag refers to your fingerprint being up for long lived circuits. Being on a dynamic up won’t change that. So in principle the stable flag means that the server is up and reach able for most of the time no matter what the address or IP may be. Thanks, John Csuti > On Jan 26, 2020, at 11:37 PM, Jonathan Marquardt <mail(a)parckwart.de> wrote: >

1 0

Tor activities - FOSDEM and OFFDEM 2020
by gus 24 Jan '20

24 Jan '20

Hello folks, Tor Project is running some activities during FOSDEM and OFFDEM this year. We look forward to seeing you there! cheers, Gus ::FOSDEM:: - Tor Meetup Track: BOFs (Track A) Room: J.1.106, Saturday, 14:00 - 15:00 - State of the Onion: The Road to Mainstream Adoption and Improved Censorship Circumvention (Track: Internet) Room: Janson, Saturday, 17:00 - 17:50 - An Introduction to the Tor Ecosystem for Developers DI&P devroom, Sunday, 13:30 - 14:00 ::OFFDEM:: - Saturday morning, Ask Tor Anything: https://ps.zoethical.org/t/ask-tor-anything/3212/3 ::More info:: https://blog.torproject.org/tor-fosdem-2020-brussels https://trac.torproject.org/projects/tor/wiki/org/meetings/2020Brussels

1 0

ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02
by nusenu 23 Jan '20

23 Jan '20

Hi, I made some updates to the ContactInfo Information Sharing Specification draft. Most notably I added a new field 'verifyurl' that should allow the automatic verification of the operatorurl claim. Without it anyone could claim to be part of some operator without the possibility of automated verification. You can get the current version on github: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification/blo… Please send me your comments before 2020-02-02. I'm planing to tag a v1.0 in February 2020. After that I hope it sees some adoption by major operators so I can use your ContactInfo strings for automated verification and as input for malicious relay detection. thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu

4 8

New Relay by the Chaos Computer Club Vienna (C3W)
by MacLemon 23 Jan '20

23 Jan '20

Hi! I just wanted to convey some happy news: The Chaos Computer Club Vienna[0] (C3W, Vienna/Austria) just launched their second relay. We're still working on tweaking the bandwidth announcements. Of course feedback to our relay setup is highly welcome and if you have questions, I'm happy to answer them. Feel free to poke around the metrics[1]. Best regards MacLemon [0]:https://c3w.at/ "Chaos Computer Club Vienna" [1]:https://metrics.torproject.org/rs.html#search/C3W "C3W Relay Overview, Tor Metrics"

2 1

bwauths don't like one of my relays?
by trusting.mcnulty＠protonmail.com 21 Jan '20

21 Jan '20

Hello, relatively new relay operator here. I originally started running a relay on a Scaleways/Online.net VPS that had extra capacity; saw the line in the Tor FAQ about how them+OVH+Hetzner own the vast majority of relay capacity; decided to hunt around for some other cheap VPS providers to give more capacity and diversity to the network. One of these relays, 'kima' (fingerprint 54A35E582F9E178542ECCFA48DBE14F401729969), is on ASN 11878, in a datacenter in Chicago, USA. It has plenty of bandwidth available to it -- iperf3 output between it, a public iperf3 server, and my two other relays is at the end of the mail. The summary is that I seem to have in excess of 100Mbps of bandwidth available. However the bwauths are consistently giving it poor scores, and as such I'm not seeing any traffic even after several days: faravahar: bw=88 moria1: bw=47 gabelmoo: bw=74 bastet: bw=2 longclaw: bw=1 The relay in question seems well-connected to the Internet, and is even relatively close to many of these bwauths: 7 hops and ~2ms away from faravahar, 12 hops and 25ms away from moria1, 10 hops and 52ms away from bastet... Is this a problem with my relay, or something fishy with the bwauth network? What can I do about this, if anything? Thanks! -Jimmy == iperf3 output: == Connecting to host iperf.he.net, port 5201 [ 5] local 107.152.35.167 port 44742 connected to 216.218.207.42 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 40.2 MBytes 337 Mbits/sec 0 5.80 MBytes [ 5] 1.00-2.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 2.00-3.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 3.00-4.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 4.00-5.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 5.00-6.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 6.00-7.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 7.00-8.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 8.00-9.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes [ 5] 9.00-10.00 sec 62.5 MBytes 524 Mbits/sec 0 5.80 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 603 MBytes 506 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 603 MBytes 506 Mbits/sec receiver iperf Done. Connecting to host iperf.he.net, port 5201 Reverse mode, remote host iperf.he.net is sending [ 5] local 107.152.35.167 port 44746 connected to 216.218.207.42 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 16.8 MBytes 141 Mbits/sec [ 5] 1.00-2.00 sec 24.2 MBytes 203 Mbits/sec [ 5] 2.00-3.00 sec 26.9 MBytes 226 Mbits/sec [ 5] 3.00-4.00 sec 25.1 MBytes 210 Mbits/sec [ 5] 4.00-5.00 sec 21.3 MBytes 179 Mbits/sec [ 5] 5.00-6.00 sec 17.1 MBytes 144 Mbits/sec [ 5] 6.00-7.00 sec 17.0 MBytes 142 Mbits/sec [ 5] 7.00-8.00 sec 17.8 MBytes 149 Mbits/sec [ 5] 8.00-9.00 sec 18.4 MBytes 154 Mbits/sec [ 5] 9.00-10.00 sec 18.7 MBytes 157 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 210 MBytes 176 Mbits/sec 336 sender [ 5] 0.00-10.00 sec 203 MBytes 171 Mbits/sec receiver iperf Done. Connecting to host dangelo.nucleosynth.space, port 5201 [ 5] local 107.152.35.167 port 51112 connected to 185.234.72.43 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 6.80 MBytes 57.0 Mbits/sec 0 3.49 MBytes [ 5] 1.00-2.00 sec 28.8 MBytes 241 Mbits/sec 0 6.01 MBytes [ 5] 2.00-3.00 sec 27.5 MBytes 231 Mbits/sec 0 6.01 MBytes [ 5] 3.00-4.00 sec 28.8 MBytes 241 Mbits/sec 0 6.01 MBytes [ 5] 4.00-5.00 sec 28.8 MBytes 241 Mbits/sec 0 6.01 MBytes [ 5] 5.00-6.00 sec 27.5 MBytes 231 Mbits/sec 0 6.01 MBytes [ 5] 6.00-7.00 sec 27.5 MBytes 231 Mbits/sec 0 6.01 MBytes [ 5] 7.00-8.00 sec 30.0 MBytes 252 Mbits/sec 0 6.01 MBytes [ 5] 8.00-9.00 sec 27.5 MBytes 231 Mbits/sec 0 6.01 MBytes [ 5] 9.00-10.00 sec 27.5 MBytes 231 Mbits/sec 0 6.01 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 261 MBytes 219 Mbits/sec 0 sender [ 5] 0.00-10.11 sec 261 MBytes 216 Mbits/sec receiver iperf Done. Connecting to host dangelo.nucleosynth.space, port 5201 Reverse mode, remote host dangelo.nucleosynth.space is sending [ 5] local 107.152.35.167 port 51116 connected to 185.234.72.43 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 5.58 MBytes 46.8 Mbits/sec [ 5] 1.00-2.00 sec 17.6 MBytes 148 Mbits/sec [ 5] 2.00-3.00 sec 24.0 MBytes 202 Mbits/sec [ 5] 3.00-4.00 sec 29.2 MBytes 245 Mbits/sec [ 5] 4.00-5.00 sec 26.4 MBytes 222 Mbits/sec [ 5] 5.00-6.00 sec 29.1 MBytes 244 Mbits/sec [ 5] 6.00-7.00 sec 27.1 MBytes 227 Mbits/sec [ 5] 7.00-8.00 sec 28.2 MBytes 237 Mbits/sec [ 5] 8.00-9.00 sec 27.7 MBytes 233 Mbits/sec [ 5] 9.00-10.00 sec 27.8 MBytes 233 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.11 sec 246 MBytes 204 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 243 MBytes 204 Mbits/sec receiver iperf Done. Connecting to host mcnulty.nucleosynth.space, port 5201 [ 5] local 107.152.35.167 port 48354 connected to 51.158.165.51 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 6.66 MBytes 55.8 Mbits/sec 0 3.54 MBytes [ 5] 1.00-2.00 sec 28.8 MBytes 241 Mbits/sec 0 6.03 MBytes [ 5] 2.00-3.00 sec 28.8 MBytes 241 Mbits/sec 0 6.03 MBytes [ 5] 3.00-4.00 sec 27.5 MBytes 231 Mbits/sec 0 6.03 MBytes [ 5] 4.00-5.00 sec 28.8 MBytes 241 Mbits/sec 0 6.03 MBytes [ 5] 5.00-6.00 sec 27.5 MBytes 231 Mbits/sec 0 6.03 MBytes [ 5] 6.00-7.00 sec 28.8 MBytes 241 Mbits/sec 0 6.03 MBytes [ 5] 7.00-8.00 sec 28.8 MBytes 241 Mbits/sec 0 6.03 MBytes [ 5] 8.00-9.00 sec 28.8 MBytes 241 Mbits/sec 0 6.03 MBytes [ 5] 9.00-10.00 sec 27.5 MBytes 231 Mbits/sec 0 6.03 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 262 MBytes 219 Mbits/sec 0 sender [ 5] 0.00-10.10 sec 261 MBytes 217 Mbits/sec receiver iperf Done. Connecting to host mcnulty.nucleosynth.space, port 5201 Reverse mode, remote host mcnulty.nucleosynth.space is sending [ 5] local 107.152.35.167 port 48358 connected to 51.158.165.51 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 5.25 MBytes 44.0 Mbits/sec [ 5] 1.00-2.00 sec 11.8 MBytes 98.6 Mbits/sec [ 5] 2.00-3.00 sec 13.2 MBytes 111 Mbits/sec [ 5] 3.00-4.00 sec 9.09 MBytes 76.3 Mbits/sec [ 5] 4.00-5.00 sec 7.99 MBytes 67.0 Mbits/sec [ 5] 5.00-6.00 sec 7.68 MBytes 64.5 Mbits/sec [ 5] 6.00-7.00 sec 8.18 MBytes 68.6 Mbits/sec [ 5] 7.00-8.00 sec 8.74 MBytes 73.3 Mbits/sec [ 5] 8.00-9.00 sec 8.22 MBytes 69.0 Mbits/sec [ 5] 9.00-10.00 sec 8.26 MBytes 69.3 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.10 sec 91.1 MBytes 75.6 Mbits/sec 633 sender [ 5] 0.00-10.00 sec 88.4 MBytes 74.1 Mbits/sec receiver iperf Done.

2 2

TCP CCA for Tor Relays (and especially Bridges)
by Matt Corallo 20 Jan '20

20 Jan '20

I’m sure this exists somewhere so this is more of a request-for-links, but what’s the current thinking on TCP CCA selection for Tor relays? While it has fairness issues (and reported long-tail issues for higher-latency links, though I can’t find good in-practice analysis of this), BBA should handle random packet loss much better than, eg, Cubic. This is likely less of an issue for western users, but many other parts of the world (especially China) see much higher packet loss due to regularly-overloaded links. I presume it is not good practice to change the default CCA for relays/bridges, but it seems BBA/BBAv2 would be a worthwhile experiment to see if it improves the browsing experience for non-western tor users. Matt

5 7

Relay with odd behavior
by Clément Février 15 Jan '20

15 Jan '20

Hi, I am running a tor relay on Ubuntu 18.04 in a LXD container. After upgrading form tor version 0.4.2.5-1~bionic+1 over 0.4.1.6-1~bionic+1, my relay is having an odd behavior. My relay is running for 9 days and the number of connections dropped from from ~5000 with 0.4.1.6-1 to 9 or less with 0.4.2.5-1. In addition, my relay does not appear anymore on https://metrics.torproject.org The fingerprint is 33D88F331408141F2A2CC563239E54E48F7A211B IPs are 151.127.52.79 and 2001:41d0:fecf:8900:216:3eff:fe8a:e4a6 Regards, Clément

2 1

Can anyone help with this issue?
by John Csuti 15 Jan '20

15 Jan '20

$ sudo apt update Hit:1 http://us.archive.ubuntu.com/ubuntu xenial InRelease Hit:2 http://us.archive.ubuntu.com/ubuntu xenial-updates InRelease Hit:3 http://us.archive.ubuntu.com/ubuntu xenial-backports InRelease Hit:4 http://security.ubuntu.com/ubuntu xenial-security InRelease Ign:5 http://download.webmin.com/download/repository sarge InRelease Ign:6 https://deb.torproject.org/torproject.org xenial InRelease Hit:7 http://download.webmin.com/download/repository sarge Release Err:8 https://deb.torproject.org/torproject.org xenial Release server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none Reading package lists... Done E: The repository 'https://deb.torproject.org/torproject.org xenial Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. $ date Mon Jan 6 04:32:36 EST 2020 I have fixed this before but I am not sure how I did it :( --John

6 7

[Event] Tor relays operators meetup, 08/11/2019 @ Mundo B, Brussels
by Vasilis 15 Jan '20

15 Jan '20

Dear Tor friends and relay operators, On Friday 8th of November 2019, a Tor relay operators meetup will take place at Mundo B in Belgium. When: Friday, November 8th, 2019 Time: 18:00 (6:00 PM) Where: Mundo B, Rue d'Edimbourg 26, Brussels, Belgium (in a room upstairs) OSM: https://www.openstreetmap.org/way/139078492#map=17/50.83787/4.36425 Event link: https://blog.torproject.org/events/tor-meetup-brussels Hope to see many of you there. Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Public key: https://keys.openpgp.org/vks/v1/by-fingerprint/8FD5CF5F39FC03EBB38274705FBF…

1 1

Fallback Relay address Changed :-(
by jan＠wth.in 15 Jan '20

15 Jan '20

Hi Guys, I moved my two relays to a new location and was not able to keep them on the same IP address. Which is quite unfortunate, since on of the was a fallback relay. https://metrics.torproject.org/rs.html#details/50586E25BE067FD1F739998550ED… https://metrics.torproject.org/rs.html#details/40C773D9F2B16143CDB2ADB661DD… I am not planing to move again within the next decade. So feel free to add the new address to the fallback list. Old address 212.51.134.123 new address 212.51.149.23. Have a nice day, Jan

2 1

Advices about Tor Network in general...
by Hugo Claude 08 Jan '20

08 Jan '20

Hello everyone, I've became recently engaged agaisnt Mass surveillance program. So I'm currently running my RPi 3B+ as a Tor Relay on my home network and i wanted to know multiple things which was unclear for me. 1. Is it possible to choose my relay as my guard relay while i'm using Tor Network ? 2. Why my relay is running on 4.1.5 while some are 4.2.5 ect... ? 3. How can i make a kind of proxy to make my entire traffic passing through Tor (like Orbot on mobile phone). 4. What kind of low-budget servers (-100€), i can buy for running ≈12MB/s Relays ? Sincerely Yours, Hugo.

3 2

%include in torrc
by ylms 08 Jan '20

08 Jan '20

Hello Is arm supposed to complain about the line with the %include as "The torrc differs from what tor's using. You can issue a sighup to reload the torrc values....". It also complains, that the ExitPolicy, which is now in an %include file, is missing. So that seems to be bogus. Tor 0.4.2.5 in this particular case. Thanks yl

4 4

Tor Organizations Meetup during 36c3 in Leipzig (Germany)
by ml-torrelays＠artikel5ev.de 07 Jan '20

07 Jan '20

Hello everyone, during the 36c3 we organized a Tor Assembly, same as in 2017/2018. The 36c3 is the annual congress of the Germany CCC (Chaos Computer Club), which is a gathering of 17.000 people of the hacking community. I has grown a lot and people from all over the world are attending. We also had two sessions, one was a relay operator meetup with FAQ and a presentation [1] of "Foundation of Applied Privacy" about their Exits. The other session was a Tor organizations meetup. During the organizations meetup some notes were taken and it was agreed to share those afterwards. [1] https://appliedprivacy.net/presentations/ The following topics were discussed: + Concentration of Tor exit capacity in unique entities, how much of the Tor (exit) capacity should be in control of one group or person? ++ This is a recurring discussion, various people have suggested limits between 5% and 10% exit probability. ++ Frënn vun der Ënn are working on a "Tor Organization Code of Conduct" including such a self-limitation - This was only mentioned by some participants and is not first hand information. + Professionalization of operation and administration, challenges in finding/keeping volunteers. ++ One organization is running on "grown" infrastructure that is administrated by Perl scripts, which new volunteers are having difficulties working with. ++ Sharing documentation/code used by various organizations might be a solution, this has also been asked for at the Tor Relay Operator Meetup. + Why are people scared of abuse? What problem does a hosting provider face if abuse happens/is not stopped? ++ At least for most servers rented from ISPs, if you don't react to abuse email in a timely manner, they will disconnect you. ++ On a higher level, there seems to be a risk for ASNs with too much unchecked abuse. + Procurement of hardware ++ One organization mentioned CPU load issues if they allow port 22 exit traffic. Better hardware might help them. ++ If you can donate relatively modern server hardware to Tor organization, please consider mentioning this on tor-relays mailing list. + Handing over the administration of Torservers.net has not progressed very much. ++ Original post: https://lists.torproject.org/pipermail/tor-relays/2019-May/017269.html ++ One problem could be a lack of information about the type and amount of work that needs to be done. ++ Handling press inquiries has been taken over by a group of other organizations, seems to be working well. + IPv6 ++ Some major Tor exit operator might loose their IPv4 space within the next 2-3 years, which makes progress in the IPv6 area crucial for them to continue contributing to the network. ++ The Tor Project got IPv6 funding from RIPE NCC, but in addition to the software portion (Tor Project responsibility) also operators need to take action and ensure they have IPv6 connectivity enabled on their systems. + BGP Routing Security ++ BGPalerter is an easy to use tool to monitor your ASN for hijacking attempts and visibility issues nitor your ASN for hijacking attempts and visibility issues https://github.com/nttgin/BGPalerter + Future meetings ++ Some organizations wish to be invited to the Tor meetings. People of some organizations attend the meetings aready through other means. The meetup took 90 minutes, in the end it was decided to organize a meetup like this each year. Quarterly mumble meetings are to be held. Some of the organizations present (in alphabetical order) were: Artikel10 - https://artikel10.org/ Artikel 5 e.V. - https://www.artikel5ev.de/ Digitalcourage - https://digitalcourage.de/en Digitale Gesellschaft - https://www.digitale-gesellschaft.ch/ Emerald Onion - https://emeraldonion.org/meraldonion.org/meraldonion.org/meraldonion.org/me… F3 Netze - https://f3netze.de/ Foundation for Applied Privacy - https://applied-privacy.net/ Nos Oignons - https://nos-oignons.net/ Zwiebelfreunde - https://www.zwiebelfreunde.de/ This text was composed in a pad by various people, the license of the text is CC-BY-SA 3.0, original text can be found here: https://cryptpad.fr/pad/#/2/pad/edit/eMjLydN6sIQSMbHwNwzIUHDL/ // End of protocol I hope there is no information missing, I shared the pad and some people were working on the text in the last 3 days, please feel free to discuss the topics mentioned and also feel free to add information missing. -- utzer Twitter: @utzer mailto:info@artikel5ev.de

6 9

tor crash on HUP only when SANDBOX is 1
by tor-relay＠riseup.net 06 Jan '20

06 Jan '20

Hi, I'm running an exit relay on a Debian Buster. I installed libseccomp and I've built tor 0.4.2.5 using debuild, like the wiki says. Today I noticed that tor crashes on HUP signal, only when the Sandbox option is on. I never had this problem. This is what my log says: an 05 08:23:10.000 [notice] Received reload signal (hup). Reloading config and resetting internal state. Jan 05 08:23:10.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Jan 05 08:23:10.000 [notice] Read configuration file "/etc/tor/torrc". Jan 05 08:23:10.000 [notice] Tor 0.4.2.5 opening log file. ============================================================ T= 1578205390 (Sandbox) Caught a bad syscall attempt (syscall dup) /usr/bin/tor(+0x1fc9fa)[0x561d896b29fa] /lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f0bebf4bbc7] /lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f0bebf4bbc7] /usr/bin/tor(tor_log_update_sigsafe_err_fds+0x18b)[0x561d896c699b] /usr/bin/tor(set_options+0x3c0)[0x561d89642f80] /usr/bin/tor(options_init_from_string+0x17d)[0x561d896453dd] /usr/bin/tor(options_init_from_torrc+0x404)[0x561d89645a74] /usr/bin/tor(+0x5f961)[0x561d89515961] /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22a6c)[0x7f0bec5a3a6c] /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)[0x7f0bec5a4537] /usr/bin/tor(do_main_loop+0xff)[0x561d8952a3af] /usr/bin/tor(tor_run_main+0x1105)[0x561d89517d55] /usr/bin/tor(tor_main+0x3a)[0x561d8951523a] /usr/bin/tor(main+0x19)[0x561d89514df9] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f0bebe8509b] /usr/bin/tor(_start+0x2a)[0x561d89514e4a] I'm telling you because i think it could be a bug, but I'm not sure that It's not caused by something else. At the moment I've disabled Sandbox. Please, let me know if I can fix this in some way, thanks.

4 5

relayor v20.0.0 is released
by nusenu 06 Jan '20

06 Jan '20

Hi, relayor v20.0.0 is released. relayor is an Ansible role that aims to help you with running relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor Changes: https://github.com/nusenu/ansible-relayor/releases/tag/v20.0.0 kind regards, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu

1 0

Tor relay stopped working on Ubuntu 18.04 in LXD container after update to 0.4.2.5-1~bionic+1
by Clément Février 02 Jan '20

02 Jan '20

Hello, I am running a tor relay on Ubuntu 18.04 in a LXD container. After upgrading form tor version 0.4.2.5-1~bionic+1 over 0.4.1.6-1~bionic+1, it stopped working. Here what I have in /var/log/syslog Dec 23 13:22:29 tor systemd[1]: tor(a)default.service: Failed to reset devices.list: Operation not permitted Dec 23 13:22:29 tor systemd[1]: Failed to set devices.allow on /system.slice/system-tor.slice/tor(a)default.service: Operation not permitted Dec 23 13:22:29 tor systemd[1]: message repeated 2 times: [ Failed to set devices.allow on /system.slice/system-tor.slice/tor(a)default.service: Operation not permitted] Dec 23 13:22:29 tor tor[5887]: Dec 23 13:22:29.582 [notice] Tor 0.4.2.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. Dec 23 13:22:29 tor tor[5887]: Dec 23 13:22:29.582 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Dec 23 13:22:29 tor tor[5887]: Dec 23 13:22:29.582 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Dec 23 13:22:29 tor tor[5887]: Dec 23 13:22:29.582 [notice] Read configuration file "/etc/tor/torrc". Dec 23 13:22:29 tor tor[5887]: Dec 23 13:22:29.583 [notice] Based on detected system memory, MaxMemInQueues is set to 6260 MB. You can override this by setting MaxMemInQueues by hand. Dec 23 13:22:29 tor tor[5887]: Dec 23 13:22:29.584 [warn] ControlPort is open, but no authentication method has been configured. This means that any program on your computer can reconfigure your Tor. That's bad! You should upgrade your Tor controller as soon as possible. Dec 23 13:22:29 tor systemd[1]: Failed to set devices.allow on /system.slice/system-tor.slice/tor(a)default.service: Operation not permitted Dec 23 13:22:29 tor tor[5887]: Configuration was valid Thank you in advance for you help. Regards, Clément

1 0