- tor-relays - lists.torproject.org

This would be better in bold, methinks - IPv6 troubleshooting
by torix＠protonmail.com 10 Aug '20

10 Aug '20

An important piece of mental furniture that I never needed to know until months later when a relay stopped working is right here in Step 7: Check IPv6 Availability of page https://community.torproject.org/relay/setup/post-install/ "If you enable IPv6 without working IPv6 connectivity your entire relay will not be used, regardless if IPv4 is working." This seems to me to be quite idiosyncratic to tor, and easily forgotten - not the first thing I would think about when troubleshooting, nor is the post-install page quite where I would look for help when a relay stopped. As we move more and more to including IPv6 in our relay setups, this will come up more often. But we should at least add bold here. --Torix Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

Relay dropped all traffic
by Sebastian Elisa Pfeifer 08 Aug '20

08 Aug '20

Hey, so one of my relays [0] dropped all traffic. Tor Metrics says its down for 4 days now, but "last restarted" correctly states today at 19:06. Also, on the metrics page is has the flags Fast, Guard, Running, Stable, V2Dir, Valid and ReachableIPv6, but when I SSH into it and look in nyx, it says there "flags: none". I tried rebooting multiple times. The Log tells me "Aug 07 02:36:12.000 [notice] Heardbeat: It seems like we are not in the cached consensus." I have attached the log with the events since the last restart today at 19:06 Should I just generate new keys? Greetings, Sebastian [0] https://metrics.torproject.org/rs.html#details/A4DEEE8F4467621C0A3CB7F4E25C…

2 2

What is the command to view the tor log file on Debian?
by Keifer Bly 08 Aug '20

08 Aug '20

6 8

Availables ports for obfs4 on Fedora
by I.N.R.I. 07 Aug '20

07 Aug '20

Hi To install Tor I try to set a port for obfs4 The ports 22, 80 and 443 are used I wish to find a free port conpatible with the TCP 127.0.0.1 Or an other adress May you help me pls ? Thanks Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

Re: [tor-relays] Tor is showing it's running different versions, and continuing previous thread
by Keifer Bly 07 Aug '20

07 Aug '20

That returns "reading config failed" so no luck. Thanks anyway though! --Keifer On Fri, Aug 7, 2020 at 12:43 PM <tschador(a)posteo.de> wrote: > On 07.08.20 20:47, Keifer Bly wrote: > > > Hi all, > > > > So my relay at > > > > > https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… > > > > Says it is running two different versions, on metrics it is showing it is > > running tor 0.4.3.5 but when I log into the VPS via SSH it says it is > > running tor 0.4.3.6. It has been like this for a few days now. Something > > is also not allowing me to check tors data logs, when I check my torrc it > > says the log file is /var/log/tor/notices.log, it either just loads a > blank > > file or says the file is unwrite able. This is odd I don’t believe I did > > add any special configuration for this. > > Hi Keifer, > > on Debian you can check: tor -v; dpkg -l|grep "ii ?tor" > For me it shows: > Tor 0.4.3.6 running on Linux > ii tor 0.4.3.6-1~d10.buster+1 > ii tor-geoipdb 0.4.3.6-1~d10.buster+1 > > Next - check: ls -lA /var/log/tor > An my server it shows: > -rw-r----- 1 debian-tor adm 0 Jul 13 21:03 log > > The owner should be "debian-tor" or whatever your tor is running. > use: chown to change file owner and group > and: chmod to change file mod bits > > Good luck! >

1 0

Tor is showing it's running different versions, and continuing previous thread
by Keifer Bly 07 Aug '20

07 Aug '20

Hi all, So my relay at https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… Says it is running two different versions, on metrics it is showing it is running tor 0.4.3.5 but when I log into the VPS via SSH it says it is running tor 0.4.3.6. It has been like this for a few days now. Something is also not allowing me to check tors data logs, when I check my torrc it says the log file is /var/log/tor/notices.log, it either just loads a blank file or says the file is unwrite able. This is odd I don’t believe I did add any special configuration for this. Heads up, on my end the spam emails are coming through again. Cheers. Thanks very much. --Keifer

1 0

The “tor-relay” Well-Known Resource Identifier - IANA registration
by nusenu 07 Aug '20

07 Aug '20

Hi, as already sent to the tor-dev mailing list a week ago I planning to submit a well-known URI registration ( https://tools.ietf.org/html/rfc8615 ) so the verifyurl is at a static place and no longer needs to be specified explicitly. Please let me know if you have any comments. https://nusenu.github.io/tor-relay-well-known-uri-spec/ kind regards, nusenu -- https://mastodon.social/@nusenu

2 1

West Coast US Tor Relays Slow - Low Consensus Weight versus East Coast
by Neel Chauhan 06 Aug '20

06 Aug '20

Hi network-health@/tor-relays@ mailing lists, I noticed one thing: Tor relays on the West Coast US (and Canada) are generally slower than those on say the East Coast and in Europe. I moved to the West Coast this January, but this was not an issue in the past when looking at dedicated servers I had from the West Coast prior to this year. These are two middle relay instances on an Gigabit FTTH connection (Wave G in Redmond, WA): https://metrics.torproject.org/rs.html#details/B0F9BA27944FA59E3B1A182208FF… https://metrics.torproject.org/rs.html#details/DB710B14D7329B7289CFCC547F48… The Consensus Weight often is slower than the Advertised Bandwidth, and isn't ramping up despite having lots of bandwidth. I set RelayBandwidthRate to about 500 Mbps on each instance. This isn't just a Wave G problem, this affects almost every relay in the West Coast including other Gigabit ISPs such as AT&T (AS7018) and Sonic (AS46375), as well as hosting companies and colocation facilities. For instance, my Los Angeles-based Exit relays at Psychz Networks (AS40676) show this issue (however they are new): https://metrics.torproject.org/rs.html#details/156AAC3FAD1ACC8906316519DCB4… https://metrics.torproject.org/rs.html#details/A69CEB30328B1E85C6B167FECAF2… Even Emerald Onion has this issue: https://metrics.torproject.org/rs.html#details/09DCA3360179C6C8A5A20DDDE1C5… What is causing this issue and is there a solution? Is it backbone congestion due to COVID-19? The high load on dirauths? sbws regressions? Can I help fix this issue? I am a Core Tor contributor and am open to also working on sbws. Is there a way to optimize my relays (they run FreeBSD). -Neel === https://www.neelc.org/

2 1

FreeBSD Relays in VMware VSphere
by MacLemon 06 Aug '20

06 Aug '20

Hi! We've been having serious networking problems with a FreeBSD VM in VMware VSphere for several months now. The symptom is that network throughput slowly degrades and packet loss increases until your VM is unable to transmit any meaningful data. (Cannot SSH in anymore, etc. We're talking literally BITS per second bad.) We've been suspecting the vmx(8) networking driver for some time and now there's an update to the driver available in FreeBSD 12.1-p8. So if you're running a Relay on FreeBSD under VSphere, this should fix the issue. https://bsdsec.net/articles/freebsd-announce-freebsd-errata-notice-freebsd-… We hope that our two-in-one FreeBSD relay will be stable and passing traffic again! C3WLittleGem https://metrics.torproject.org/rs.html#details/B1F09810C4F7B9D30F483DCE3891… C3WPhantomStreak https://metrics.torproject.org/rs.html#details/C04850673F655A91F5AD3C06E1E5… C3W Family Members: https://metrics.torproject.org/rs.html#search/family:C04850673F655A91F5AD3C… Best regards MacLemon for the Chaos Computer Club Vienna/Austria

1 0

Exit relay: ERROR -- No Descriptor Available
by raspitor 05 Aug '20

05 Aug '20

After running an exit relay for a few days I see the message: ERROR -- No Descriptor Available on the torstatus.rueckgr.at site, and the traffic of my exit node is almost zero, also seen in nyx. Rebooting the system restarts everything normal and it is listed on the ruckgraet site, but after a day or so the problem occurs again. What might ne the cause of this?

2 1

Should I use Tor Alpha on my relays
by Sebastian Elisa Pfeifer 01 Aug '20

01 Aug '20

Hello, I am currently running Tor from the Tor Repositories on Debian Stable. Its working ok, but I was wondering if the network would benefit if I would start using Tor Alpha? Greetings, Sebastian

3 3

Recently very low Consensus Weight
by tor_this_too＠aol.com 01 Aug '20

01 Aug '20

Hi everyone, this is my first ever post on a mailinglist, so bare with me if I'm doing it wrong... I've been running a relay for some time now and recently the traffic dropped neraly completely https://metrics.torproject.org/rs.html#details/564A7F1D0314125AF60096CDE0A8… Consensus Weight is down to 71 and I wonder why this is the case? The relay was recently rebooted (just in case) and all other traffic I may initiate from this server is without a problem and at max speed. Any ideas?

1 0

Upgrading Linux Mint to Ulyana
by Anonforpeace 30 Jul '20

30 Jul '20

Hello: I am running my bridge on Linux Mint and there is an upgrade to the latest version, Linux Mint 20, Ulyana. I'd like to perform the upgrade, buy my question is, is there a way to do it without having to reconfigure the bridge entirely?

2 1

Guard flag got removed after only 48 hours of downtime.
by William Kane 28 Jul '20

28 Jul '20

1 0

Recover AccountingMax counter
by Camie Hethcote 28 Jul '20

28 Jul '20

Hi guys ! I had to reset tor service which led to AccountingMax counter reset. I'm already out of traffic limit so can I somehow recover this counter or should I wait until limit reset from my provider and then start tor service again? Thanks ! Camie

1 0

Unable to Automate TOR Browser | Python
by ABDAL LALIT 27 Jul '20

27 Jul '20

Hi, I'm trying to automate TOR Browser for anonymous scraping using python. The code is given below: from selenium import webdriver from selenium.webdriver.firefox.firefox_profile import FirefoxProfile from selenium.webdriver.firefox.firefox_binary import FirefoxBinary binary = FirefoxBinary("C://Tor Browser//Browser//firefox.exe") driver = webdriver.Firefox(firefox_binary = binary) def interactWithSite(driver): driver.get("https://www.google.com") driver.save_screenshot("screenshot.png") This is the preliminary code I used as a building block. I am receiving an error message, while running the code as follows: The pop-up is as [image: image.png] While the error shown in the code is as follows [image: image.png] [image: image.png] [image: image.png] I request the team to kindly help me with this issue. I'm really stuck and thus am unable to build up my project further

1 0

ContactInfo Information Sharing Specification Version 1 released
by nusenu 26 Jul '20

26 Jul '20

Hi, I'm happy to finally announce version 1 of the ContactInfo Information Sharing Specification: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification This is an effort that started in 2017 as you can see on github. Tor's ContactInfo field was primarily intended to contain an email address and PGP key fingerprint but since this field accepts an arbitrary string it has been used for multiple other purposes (website urls, donation information, bitcoin addresses, ...). This is a specification to formalize the ContactInfo string to: - make provided information machine readable (could be used for Relay Search) - improve the ability to contact relay operators - allow the automatic attribution and verification that a relay is operated by a given entity - increase information sharing among tor relay operators Eran Sandler created a nice and simple to use generator based on the specification: https://torcontactinfogenerator.netlify.app/ If you used the generator and specification in the past, please regenerate your ContactInfo string, so it includes the version field. I'm particularly looking forward to seeing many use the verifyurl field. Overview of definied fields email pgp abuse operatorurl verifyurl keybase twitter mastodon matrix xmpp otr3 ricochet hoster cost uplinkbw trafficacct memory cpu virtualization bitcoin zcash donationurl offlinemasterkey signingkeylifetime sandbox os tls aesni autoupdate confmgmt dnslocation dnsqname dnssec dnslocalrootzone CIISSversion regards, nusenu -- https://mastodon.social/@nusenu

9 15

Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)
by tor-operator 26 Jul '20

26 Jul '20

Dear Gus or whoever it may concern; I was unable to reply before the deadline due to an unforeseeable issue which came up. That has now been cleared up and I hope it'll be fine to participate. At any rate, here are the ones which I'd like to opt-in: k0nslNET14: https://metrics.torproject.org/rs.html#details/8C5155E33148B13CEF02197037D8… k0nslNET1488: https://metrics.torproject.org/rs.html#details/239E373B108E04912B3AF8C32E99… k0nslNET7: https://metrics.torproject.org/rs.html#details/F1B6FA0ED8C60E9C7317AF027E7C… k0nslNET1889: https://metrics.torproject.org/rs.html#details/0E8FD4368083BD7817A42F3ECEDE… They all support IPv6 as well. All the best! Faithfully -k0nsl

1 0

an alternative to verifyurl
by nusenu 24 Jul '20

24 Jul '20

Hi, based on feedback I got about https://github.com/nusenu/ContactInfo-Information-Sharing-Specification I want to add an additional verification option based on DNS records to allow for the same verification as the verifyurl field provides but without the need to have a webserver and a proper TLS certificate. Explained by example: Lets say the operator has the domain example.com and runs a relay with fingerprint ABCF46A63F9C21FD315CD061B3EAA3EB05283ABC on IP addresses: 192.0.2.235 The operator would simply create the following DNS record for verification/linking: DNS A record: ABCF46A63F9C21FD315CD061B3EAA3EB05283ABC.example.com pointing to 192.0.2.235 If the relay has an IPv6 address as well an AAAA record is created for the same name pointing to the IPv6 address. Since we require a TLS certificate for verifyurl this will require DNSSEC to be enabled on the domain to be validated. Let me know if you have any feedback on this additional option. thanks! nusenu -- https://mastodon.social/@nusenu

1 0

generating graphs of "attributable" operators using ContactInfo/verifyurl
by nusenu 21 Jul '20

21 Jul '20

nusenu wrote [1]: > I'm generating some timeseries graphs now to see what (exit) fraction (stacked) > is managed by > https://torservers.net/partners.html > and those mentioned at the bottom of > https://lists.torproject.org/pipermail/tor-relays/2020-January/018022.html > + some custom additions for operators I had some contact before > over time (past 6 months). > spoiler: it used to be >50% until some malicious actor came along and reduced it to <50% I was still fiddling around with this by looking through the list of operators sorted by their network fraction of the overall capacity to add more to the "attributable" pool, but it is rather time consuming, especially if we aim to generate them on a regular basis. To allow for better automation/scalability in this effort I'd like to ask operators to use the ContactInfo string generator https://torcontactinfogenerator.netlify.app/ in particular the operatorurl and verifyurl fields. This will allow me to automate the time consuming job and generate some nice timeseries graphs. Please let me know if you have any questions. Looking forward to seeing many ContactInfo strings containing operatorurl and verifyurl fields. thanks, nusenu [1] https://lists.torproject.org/pipermail/tor-relays/2020-July/018660.html -- https://mastodon.social/@nusenu

1 0

tor relay - vps maintenance - what to do ?
by dlugasny＠protonmail.com 21 Jul '20

21 Jul '20

Hi, in the next three days, my VPS provider planning to shutdown ("maintenanance") for 6 hours my VPS where tor relay is running (with some services). What should I do ? I suspect that my VPS will be copied and reviewed (by not authorized persons) afterwards. How do You react in such a situations ? I appreciate any advice. Cheers Dlugasny Sent with [ProtonMail](https://protonmail.com) Secure Email.

6 5

Directory Authority servers still using excessive bandwidth
by Neel Chauhan 20 Jul '20

20 Jul '20

Hi tor-relays@, I have noticed that despite fixing bugs in the past, the directory authority relays are still using excessively high amounts of bandwidth, when looking at Relay Search: Examples: * https://metrics.torproject.org/rs.html#details/7EA6EAD6FD83083C538F44038BBF… * https://metrics.torproject.org/rs.html#details/9695DFC35FFEB861329B9F1AB04C… * https://metrics.torproject.org/rs.html#details/BD6A829255CB08E66FBE7D374836… And many more. I'm asking since I'm having an issue with low consensus weights on a symmetrical "Gigabit" pipe, and I am suspecting the overloaded authority servers are a factor. Are they? It could also be my current ISP's (Wave Broadband) crap peering, but would I really want to use Comcast? -Neel === https://www.neelc.org/

1 0

Re: [tor-relays] Error from LZMA encoder
by nottryingtobelame＠protonmail.com 20 Jul '20

20 Jul '20

This bridge is on Digital Ocean, so I checked my logs and it doesn't appear that my memory usage ever maxed. It hovers right around 80 with the highest spike at about 87%. Is that insufficient? Thank you for the reply.

1 0

Error from LZMA encoder: Unable to allocate memory; NULL stream while compressing
by nottryingtobelame＠protonmail.com 20 Jul '20

20 Jul '20

My bridge was running fine, then started throwing the same error over and over. See my last two days of logs here: https://pastebin.com/7FNXC6PZ. Function doesn't seem to be affected as the heartbeats still show users. Can or should I do anything about this?

2 1

trouble with tor relay software on debian
by Keifer Bly 20 Jul '20

20 Jul '20

Hi all, So my middel guard relay at https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… As well as my bridge at https://metrics.torproject.org/rs.html#details/EF36AE38C162E96E0645E1DF25EF… Are not updating, though I had configured them to be updated by unattended upgrades they are stuck on tor 4.3.5. When running sudo apt update && sudo apt install -y --only-upgrade tor This is the return, it's a google drive link to the screenshot as copy pasting the text ended up in a jumbled mess. https://drive.google.com/file/d/1ULtvt8B28tTwN5DI7oLmfj7mbfBIDh6A/view?usp=… It says ip address not found, I wonder why this is as I had imported tors keyring before hand. What's also going on is, I am trying to see how much traffic my relay has pushed but am not able to open the log file, when using less /var/log/tor/notices.log I am only seeing a black screen with (END) and that's it. I wonder why this is. Thanks very much, --Keifer <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>

3 2

Snowflake-proxy restricted NAT
by dmz21 19 Jul '20

19 Jul '20

Hi, I've been running a Snowflake (the stand-alone Go-proxy kind build from source) as a Debian service. I was working fine before, showing a handful of anonymous connections per day. Recently it shows a new log message: "NAT type: restricted" after "starting" and I have not seen any new connections. I'm guessing that a restricted NAT does not allow any client to connect to my VM. Please tell me if I'm wrong. I don't think that I have made any relevant changes to my network or hypervisor setup, recently. I don't know how to configure my OpenWrt router such that I have a suitable NAT to a specific IP in my DMZ. Can anyone tell me what I could try in order to restore my Snowflake-proxy to being useful to others again? kind regards and thanks

2 2

Noticeable Increase in Abuse Traffic
by John Ricketts 19 Jul '20

19 Jul '20

All, I'm getting about 4x the abuse traffic that I normally get from running exits. Anyone else noticing this trend? John Ricketts Quintex Alliance Consulting

4 6

Re: [tor-relays] Noticeable Increase in Abuse Traffic
by info＠backplanedns.org 19 Jul '20

19 Jul '20

I noticed this too. I've gotten about 4-5 abuse complaints to my upstream provider alone in the last few days. A few more directly to my email. According to the abuse report logs they all appear to be a similar xss exploit attempt. DennisSent from my T-Mobile 4G LTE device------ Original message------From: John RickettsDate: Sat, Jul 18, 2020 8:42 PMTo: tor-relays(a)lists.torproject.org;Cc: Subject:[tor-relays] Noticeable Increase in Abuse TrafficAll, I'm getting about 4x the abuse traffic that I normally get from running exits. Anyone else noticing this trend? John Ricketts Quintex Alliance Consulting _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Please help us find a working alternative to using MaxMind's GeoLite2 databases
by Karsten Loesing 14 Jul '20

14 Jul '20

Hi relay operators, as you might have heard, MaxMind has changed access and use of their GeoLite2 databases: https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-us… This affects Onionoo and tor, and I'm trying to find a working alternative on the following ticket: https://trac.torproject.org/projects/tor/ticket/32978 Today I think I found a possible alternative by using data from another provider. But before I name it here, I'd first want to find out how accurate it is. I tried resolving relay IP addresses of relays that have been running in the past week and compared that to our existing lookups using MaxMind's October database. The result is that 7669 relays (93%) had the same country code and ASN. I put the remaining 7% on the following wiki page: https://trac.torproject.org/projects/tor/wiki/doc/MetricsGeoipComparison I'd like to hear from you which data source is right and which is wrong (or if both are wrong). If you'd like to help, please leave comments on the ticket or in the "Comment" column on that wiki page by February 19, 2020. Thanks for helping! All the best, Karsten

12 14

>23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
by nusenu 13 Jul '20

13 Jul '20

Hi, I'm currently writing a follow-up blog post to [1] about a large scale malicious tor exit relay operator that did run more than 23% of the Tor network's exit capacity (May 2020) before (some) of it got reported to the bad-relays team and subsequently removed from the network by the Tor directory authorities. After the initial removal the malicious actor quickly restored its activities and was back at >20% of the Tor network's exit capacity within weeks (June 2020). [1] https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-t… To prevent this from happening over and over again I'm proposing two simple but to some extend effective relay requirements to make malicious relay operations more expensive, time consuming, less sustainable and more risky for such actors: a) require a verified email address for the exit or guard relay flag. (automated verification, many relays) b) require a verified physical address for large operators (>=0.5% exit or guard probability) (manual verification, low number of operators). It is not required that the address is public or stored after it got verified. For details see bellow [2]. 0.5% exit probability is currently about 500-600 Mbit/s of advertised bandwidth. Q: How many operators would be affected by the physical address verification requirement if we use 0.5% as a threshold? A: About 30 operators. There are currently about 18 exit [3] and 12 guard operators that run >0.5% exit/guard capacity if we ignore the fresh exit groups from 2020. Most exit operators (14 out of these 18) are organizations with public addresses or have their address published in WHOIS anyway. At the end of the upcoming blog post I'd like to give people some idea as to how much support this proposal has. Please let me know if you find this idea to limit attackers useful, especially if you are a long term relay operator, one of the 30 operators running >=0.5% exit/guard capacity, a Tor directory authority operator or part of The Torproject. thanks for your support to fight malicious tor relays! nusenu -- https://mastodon.social/@nusenu [2] Physical address verification procedure could look like this: The Torproject publishes a central registry of trusted entities that agreed to verify addresses of large scale operators. The registry is broken down by area so no central entity needs to see all addresses or is in the position to block all submissions. (even though the number of physical address verifications are expected be stay bellow 50 for the time being). Examples could be: Riseup.net: US, ... Chaos Computer Club (CCC) : DE, ... DFRI: SE, ... (these organizations host Tor directory authorities) - Relay operators that would like to run more than 0.5% guard/exit fraction select their respective area and contact the entity to initiate verification. - before sending an address verification request the operator verifies that they meet the following requirements: - the oldest relay is not younger than two months (https://community.torproject.org/relay/community-resources/swag/ ) - all relays have a proper MyFamily configuration - relays include the verified email address and PGP key fingerprint in the relay's ContactInfo - at least one of their relays gained the exit or guard flag - they have a sustained bandwidth usage of at least 100 Mbit/s (accumulated) - intention to run the capacity for at least 4 months - upon receiving a request the above requirements are verified by the verification entity in addition to: - relay(s) are currently running - the address is in the entity's area - a random string is generated by the address verification entity and send with the welcome tshirt (if requested) to the operator - after sending the token the address is deleted - upon receiving the random string the operator sends it back via email to the verification entity while signing the email with the PGP key mentioned in the relays ContactInfo - the verification entity compares the received string with the generated and mailed string - if the string matches the entity sends the relay fingerprint to the directory authority list to unlock the cap for the operator After this one-time procedure the operator can add more relays as long as they are in the same family as the approved relay (no new verification needed). [3] exit operators running >=0.5% of exit probability without exit groups from 2020 (onionoo data as of 2020-07-03) abuse-contact(a)to-surf-and-protect.net 22.73 Foundation for Applied Privacy 6.05 John L. Ricketts, PhD <john AT quintex dot com> 5.6 F3 Netze <abuse(a)f3netze.de> 5.47 https://www.torservers.net 3.89 Nicholas Merrill <nick AT calyx dot com> 2.48 https://www.digitale-gesellschaft.ch/abuse/ 1.74 Accessnow.org <abuse .AT. accessnow .DOT. org> 1.71 Hart voor Internetvrijheid 1.63 <zwiebeln at online de> 1.44 TNinja <abuse-team at tor dot ninja> 1.43 tech(a)emeraldonion.org 1.31 Frenn vun der Enn FVDE 1 https://www.artikel5ev.de/torcontact/ 0.74 Nos oignons 0.71 tor-abuse<at>mailbox<dot>org 0.67 abuse-node49 AT posteo DOT de 0.57 tor-operator(a)privateinternetaccess.com 0.52 14 out of these 18 operators have their address already publicly listed because they are registered organizations or similar.

15 27

My Tor relay appears offline every 3 hours
by marsbanks 13 Jul '20

13 Jul '20

Since about 2 weeks ago, [my (non-exit) relay](https://metrics.torproject.org/rs.html#details/94626BD21119568EB301D… appears offline every 3 hours or so even though it's not actually offline. This lasts for about an hour each time, during which my relay also loses all its flags. However, it's reachable and pingable, and I still get some Tor traffic, though it's very reduced. I don't see any errors via Nyx or looking at my Tor logs. But after about an hour, everything seems to go back to normal: it comes back online, with the Fast, Running, V2Dir, and Valid flags. Does anyone have any clue what could be going on? I've been pulling my hair out trying to troubleshoot this, with no luck. And it's preventing my relay from getting the Stable flag, let alone finally becoming a Guard. Thanks in advance! Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

My relay appear down when it's actually up
by trinity Pointard 11 Jul '20

11 Jul '20

Hi, Since a few days, my relay A8503903F97FF27F5D1C3CA38817329F581925E6 appear down according to metrics.torproject.org, and is not getting the Running flag from 6 out of 9 authorities according to consensus-health.torproject.org. This happened when my ISP got an issue and my network falled back to a cellular network. Tor can't run as a relay on that network as my server isn't publicly reachable over it, but it's been 2 days since the problem was resolved, I've restarted Tor daemon half a dozen time (last restart does appear on metrics.torproject.org) and I'm still not getting the Running flag. Any idea of what I can do to put it back in working condition? I hope someone will have an idea, and I wish you all a nice day.

2 1

Re: [tor-relays] Become a Fallback Directory Mirror
by Bakullama 11 Jul '20

11 Jul '20

90B64F9E18B59AF322EBD28B8F8CD65C53E10CE1 ~ Bakullama ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, 10 July 2020 13:00, <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. Re: Become a Fallback Directory Mirror (deadline: July 23) > (William Denton) > > > Message: 1 > Date: Thu, 9 Jul 2020 18:15:05 -0400 (EDT) > From: William Denton wtd(a)pobox.com > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Become a Fallback Directory Mirror > (deadline: July 23) > Message-ID: alpine.DEB.2.02.2007091814020.311(a)shell.miskatonic.org > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > C14CE6C2145688B640EB6457F39C1C6E1DC684D4 > > Bill > > > On 08/07/20 18:36, gus wrote: > > > > > Dear Relay Operators, > > > Do you want your relay to be a Tor fallback directory mirror? > > > Will it have the same address and port for the next 2 years? > > > Just reply to this email with your relay's fingerprint. > > -- > > William Denton :: Toronto, Canada --- Listening to Art: https://listeningtoart.org/ > https://www.miskatonic.org/ --- GHG.EARTH: https://ghg.earth/ > Caveat lector. --- STAPLR: https://staplr.org/ > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Subject: Digest Footer > > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > -------------------------------------------------------------------------------------------------------------------------- > > End of tor-relays Digest, Vol 114, Issue 15

2 1

Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
by entensaison＠use.startmail.com 10 Jul '20

10 Jul '20

Hi, On Sunday, July 5, 2020 at 8:45 PM, Imre Jonk <imre(a)imrejonk.nl> wrote: > Hi nusenu, > > On Sun, 2020-07-05 at 18:35 +0200, nusenu wrote: > [...] >> b) require a verified physical address for large operators (>=0.5% >> exit or guard probability) >> (manual verification, low number of operators). >> It is not required that the address is public or stored after it got >> verified. >> For details see bellow [2]. >> >> 0.5% exit probability is currently about 500-600 Mbit/s of >> advertised >> bandwidth. > That seems reasonable. I currently co-run an exit relay that has just > under 0.1% probability and would be okay with sharing my physical > address with the directory authorities, especially if my probability > would be higher. This is a great point. Independent of the measures that will be chosen, they should impact the traffic a relay gets. Most relay operators want their relays to be useful and are willing to do put a lot of work into increasing their traffic. And they should be "rewarded" with flags so that it is obvious to relay operators that they have an interest in actually fulfilling the new requirements. > [...] >

1 0

Hardware specs for a high-bandwidth Tor exit?
by Christian Pietsch 08 Jul '20

08 Jul '20

Dear Tor friends, the NGO I am volunteering for (Digitalcourage e.V.) has been running modest Tor exits for many years. Now we finally have the opportunity to run a high-bandwidth exit relay because we found a data center with a nice internet connection (20 Gbit/s) we may use. My question is: What kind of hardware should we buy to utilize this bandwith? I am told that we need an SFP+ networking card to connect to the fibre optics cable, but what CPU and mainboard would you recommend nowadays? It should fit into a 1 height unit 19" enclosure. If you prefer to tell me in person: I will attend the Tor meetup in Brussels on Friday <https://blog.torproject.org/events/tor-meetup-brussels> and the subsequent Freedom Not Fear event <https://www.freedomnotfear.org/>. Cheers, Christian -- Christian Pietsch | volunteering for Digitalcourage e.V., Germany Digitalcourage e.V.: https://digitalcourage.de/ BigBrotherAwards Germany: https://bigbrotherawards.de/ Betting living without Google: https://pad.foebud.org/google-alternatives

3 3

Work with ISPs
by Charly Ghislain 08 Jul '20

08 Jul '20

Hi list, With the recent warning by nusenu about the malicious relays and the proposal to work around the issue , ive been wondering: Did anyone ever try to convince some isp to put a low-cap tor relay on the router of their 'unlimited bandwidth' clients? Or has there been any discussion on that matter already? I understand most would be strongly reticent, but I think some may find a commercial/marketing value in this. Thanks, Charly

2 1

Authority Nodes
by Vitor Milagres 06 Jul '20

06 Jul '20

Hi, I see the Authority Nodes are located only in North America and Europe. I would like to contribute to the TOR network as much as possible. I am currently running a node and I would like to make it an Authority Node as well. I am from Brazil and I believe it would possibly be a good idea to have a new Authority Node in South America. What are the requirements? What should I do to become one of them? FYI, the node I am running is 79DFB0E1D79D1306AF03A4B094C55A576989ABD1 Thanks, Vitor Milagres

8 9

Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale malicious actors
by niftybunny 05 Jul '20

05 Jul '20

How many of us do not have our own IP space and can already be verified by this? > On 5. Jul 2020, at 17:54, nusenu <nusenu-lists(a)riseup.net> wrote: > > Hi, > > I'm currently writing a follow-up blog post to [1] about a large scale malicious tor exit relay operator > that did run more than 23% of the Tor network's exit capacity (May 2020) before (some) of it got reported to the bad-relays team and > subsequently removed from the network by the Tor directory authorities. > After the initial removal the malicious actor quickly restored its activities and > was back at >20% of the Tor network's exit capacity within weeks (June 2020). > > [1] https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-t… > > To prevent this from happening over and over again > I'm proposing two simple but to some extend effective relay requirements > to make malicious relay operations more expensive, time consuming, > less sustainable and more risky for such actors: > > a) require a verified email address for the exit or guard relay flag. > (automated verification, many relays) > > b) require a verified physical address for large operators (>=0.5% exit or guard probability) > (manual verification, low number of operators). > It is not required that the address is public or stored after it got verified. > For details see bellow [2]. > > 0.5% exit probability is currently about 500-600 Mbit/s of advertised bandwidth. > > > Q: How many operators would be affected by the physical address verification requirement if we use 0.5% as a threshold? > A: About 30 operators. > > There are currently about 18 exit [3] and 12 guard operators that run >0.5% exit/guard capacity > if we ignore the fresh exit groups from 2020. > Most exit operators (14 out of these 18) are organizations with public addresses or have their address published in WHOIS > anyway. > > At the end of the upcoming blog post I'd like to give people some idea as to how much support this proposal has. > > Please let me know if you find this idea to limit attackers useful, especially if you are a long term relay operator, > one of the 30 operators running >=0.5% exit/guard capacity, a Tor directory authority operator or part of The Torproject. > > > thanks for your support to fight malicious tor relays! > nusenu > -- > https://mastodon.social/@nusenu > > > [2] > Physical address verification procedure could look like this: > > The Torproject publishes a central registry of trusted entities that agreed to verify addresses of large scale operators. > > The registry is broken down by area so no central entity needs to see all addresses or is in the position to block all submissions. > (even though the number of physical address verifications are expected be stay bellow 50 for the time being). > > Examples could be: > > Riseup.net: US, ... > Chaos Computer Club (CCC) : DE, ... > DFRI: SE, ... > > (these organizations host Tor directory authorities) > > > - Relay operators that would like to run more than 0.5% guard/exit fraction select their respective area and contact the entity to > initiate verification. > > - before sending an address verification request the operator verifies that they meet the following requirements: > - the oldest relay is not younger than two months (https://community.torproject.org/relay/community-resources/swag/ ) > - all relays have a proper MyFamily configuration > - relays include the verified email address and PGP key fingerprint in the relay's ContactInfo > - at least one of their relays gained the exit or guard flag > - they have a sustained bandwidth usage of at least 100 Mbit/s (accumulated) > - intention to run the capacity for at least 4 months > > - upon receiving a request the above requirements are verified by the verification entity in addition to: > - relay(s) are currently running > - the address is in the entity's area > > - a random string is generated by the address verification entity and send with the welcome tshirt (if requested) to the operator > > - after sending the token the address is deleted > > - upon receiving the random string the operator sends it back via email to the verification entity > while signing the email with the PGP key mentioned in the relays ContactInfo > > - the verification entity compares the received string with the generated and mailed string > > - if the string matches the entity sends the relay fingerprint to the directory authority list to unlock the cap for the operator > > After this one-time procedure the operator can add more relays as long as they are in the same family as the approved relay (no new verification needed). > > > [3] > > exit operators running >=0.5% of exit probability > without exit groups from 2020 > (onionoo data as of 2020-07-03) > > abuse-contact(a)to-surf-and-protect.net 22.73 > Foundation for Applied Privacy 6.05 > John L. Ricketts, PhD <john AT quintex dot com> 5.6 > F3 Netze <abuse(a)f3netze.de> 5.47 > https://www.torservers.net 3.89 > Nicholas Merrill <nick AT calyx dot com> 2.48 > https://www.digitale-gesellschaft.ch/abuse/ 1.74 > Accessnow.org <abuse .AT. accessnow .DOT. org> 1.71 > Hart voor Internetvrijheid 1.63 > <zwiebeln at online de> 1.44 > TNinja <abuse-team at tor dot ninja> 1.43 > tech(a)emeraldonion.org 1.31 > Frenn vun der Enn FVDE 1 > https://www.artikel5ev.de/torcontact/ 0.74 > Nos oignons 0.71 > tor-abuse<at>mailbox<dot>org 0.67 > abuse-node49 AT posteo DOT de 0.57 > tor-operator(a)privateinternetaccess.com 0.52 > > 14 out of these 18 operators have their address already publicly listed because they are registered organizations or similar. > > >

1 0

Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale malicious actors
by Tor-Abuse 05 Jul '20

05 Jul '20

Hi nusenu, this sounds quite useful and I would like to support it. I would be fine to do an email and physical address verifiation. Cheers Fabian Am 05.07.20 um 17:54 schrieb nusenu: > nick AT calyx dot com

1 0

Tor is reporting my bridges as offline
by Eddie 02 Jul '20

02 Jul '20

Hi, I run 2 bridges on a hosted VPS. Tor is currently showing both these as offline for the last hour or so, but I can still connect to them from a Tor Browser and looking at the local logs, they are both running quite happily. Any ideas why they are showing as offline: https://metrics.torproject.org/rs.html#search/OhNoAnother Cheers.

3 4

Exit Relay throughput
by torix＠protonmail.com 20 Jun '20

20 Jun '20

Dear List, How important is the throughput on an exit relay? I realize that more is always better, making it harder to associate exit packets with input ones at the other end. My numbers: For the same price I can buy 2 exit relays that run about 3500 to 4000 connections or one that runs about 4300 to 4700 connections. The actual daily throughput varies a good deal, but the cheaper ones show about 15-20% less throughput, at around 330 GiB/day when I look at vnstat. Can I assume 2 is almost always better than one? Or is there a threshold below which packets are too easily tracked? I have no common sense about this. TIA, --Torix Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 2

"/var/tor/diff-cache" full!
by Salvatore Cuzzilla 18 Jun '20

18 Jun '20

Hi Folks, I'm running a non-exit relay (v0.4.2.7) on OpenBSD 6.7. The amount of files within "/var/tor/diff-cache" is steadily increasing. Up to almost 6G fulfilling the /var partition to the max. Is this an expected behavior? I there any solution to overcome it? ------- :wq, Salvatore.

5 5

directory servers working on updates?
by Paul Geurts 16 Jun '20

16 Jun '20

hi, anything up this weekend? [image: image.png] gr. Paul

2 2

ymkeo changing ISP coming Thursday
by René Ladan 14 Jun '20

14 Jun '20

Hi, I'm in the process of switching ISPs and if all goes well this should be complete by coming Thursday. So my relay (ymkeo, 4E8CE6F5651E7342C1E7E5ED031E82078134FB0D) will change its external IPv4 and IPv6 addresses. It is listed as a fallback directory mirror but currently not acting as one, so someone will have to update that list :) New IPv4: 185.238.129.9 /32 New IPv6: 2a10:3781:116:: /48 Regards, René

1 0

Consensus weight/Advertised bandwidth low on "Gigabit" ISP, despite ISP equipment upgrades
by Neel Chauhan 14 Jun '20

14 Jun '20

Hi tor-relays@, I run a FreeBSD-based Tor relay across two instances on "Wave G", a Gigabit ISP in the Seattle metro. You may also know them as CondoInternet or CascadeLink, but I joined only this year on a Wave-branded service. These relays have had low consensus weights since I got the service in January. The instances are below: * https://metrics.torproject.org/rs.html#details/8FABF4D266DF95216F6C646C6D6D… * https://metrics.torproject.org/rs.html#details/CE06BA1EA45FD32A79EAF7FE6A3B… My server and router are fine, I am in the single digits in terms of CPU use on both. The same exact server and router on Verizon FiOS in New York never gave me this issue. There was an underlying ISP performance issue impacting me which led consensus weight values to be low, but my ISP has since upgraded their equipment in my building. In general, my Internet performance has improved by magnitudes. However, my consensus weight has stayed more or less flat since the equipment upgrade, instead of jumping higher. What gives? How long would it usually take for the bandwidth scanners to measure the higher bandwidths? Should I re-key my relays and start from scratch? About switching ISPs, I'm not switching to Comcast for obvious well-documented reasons, and neither CenturyLink nor Frontier/Ziply Fiber serve me, not even copper. Best, Neel Chauhan === https://www.neelc.org/

2 1

IPv6 Port
by Josh Lawson 11 Jun '20

11 Jun '20

I currently have my IPv6 connection running on port 9001. From an anti-surveillance perspective, would I be better changing the port to 80? I have IPv4 running on 443. I appreciate it!

2 3

[NYX_NOTICE] Relay unresponsive -- how to troubleshoot?
by Davin Mertens 11 Jun '20

11 Jun '20

I keep getting NYX_NOTICEs about "Relay unresponsive". They happen every few hours, and last for minutes or sometimes a couple of hours before I get a "relay resumed" message. But, I don't see anything in the actual Tor logs to indicate that anything is wrong. Does anyone know how best to troubleshoot this? I *think* it's impacting my consensus weight and making it drop, and is keeping me from getting the Guard flag. This is the relay: https://metrics.torproject.org/rs.html#details/94626BD21119568EB301D1E7677B… Thanks for any tips!

3 3

Q: Is my bridge up?
by torix＠protonmail.com 10 Jun '20

10 Jun '20

I put up a new bridge and thought things were okay; I could see outbound, sometimes inbound connections in nyx, and seemed to have some throughput in the first nyx screen. The start up log lines seem okay: "Jun 10 11:05:07.000 [notice] Bootstrapped 100% (done): Done Jun 10 11:05:07.000 [notice] Now checking whether ORPort 108.52.155.127:11340 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Jun 10 11:05:09.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 10 11:06:09.000 [notice] Performing bandwidth self-test...done. Jun 10 14:13:20.000 [notice] New control connection opened. Jun 10 15:33:16.000 [notice] No circuits are opened. Relaxed timeout for circuit 133 (a General-purpose client 1-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. Jun 10 16:25:18.000 [notice] New control connection opened." And the 6hr heartbeat seems to show stuff is happening" "Jun 10 17:05:06.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 1.91 MB and received 5.84 MB." But when I use the bridge reach-ability test at https://bridges.torproject.org/scan/ It fails to find my obfs4 port. I have the two ports port-forwarded in my local router, but when I turn on ping to the router, nmap from outside sees them as filtered. Am I sending people down a black hole? Because tor does seem to be making tor connections. TIA, --Torix Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 3

Anyone getting Failed to find node for hop #2 of our path. Discarding this circuit. on relays after update?
by s7r 10 Jun '20

10 Jun '20

Hello, I have upgraded Tor to 0.4.5.0-alpha-dev-20200609T194914Z-1~d9.stretch+1 yesterday and got this message on all relays and bridges after upgrade: [warn] Failed to find node for hop #2 of our path. Discarding this circuit. [notice] Our circuit 0 (id: 4) died due to an invalid selected path, purpose Testing circuit. This may be a torrc configuration issue, or a bug. [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. [warn] No available nodes when trying to choose node. Failing. [warn] Failed to find node for hop #2 of our path. Discarding this circuit. [warn] No available nodes when trying to choose node. Failing. [warn] Failed to find node for hop #2 of our path. Discarding this circuit. [warn] No available nodes when trying to choose node. Failing. [warn] Failed to find node for hop #2 of our path. Discarding this circuit. [warn] No available nodes when trying to choose node. Failing. [warn] Failed to find node for hop #2 of our path. Discarding this circuit. [warn] No available nodes when trying to choose node. Failing. [warn] Failed to find node for hop #2 of our path. Discarding this circuit. ... like 10-14 more times same message ... It eventually healed by itself on some relays, and on some only after another restart of the Tor process. I am only wondering if anyone else got this. What made me want to ask this is what I somehow got it on each and every relay and bridge I did the update on. Could this be triggered by a skewed clock? The virtual machines usually start with hwclock which is usually behind (virtualbox bug) and few seconds after boot ntp takes over and corrects the time. Will keep an eye on this. Things appear to run fine after it starts. Thanks.

1 0

Help via Skype teamviewer
by Pac-Man 10 Jun '20

10 Jun '20

I have everything ready to roll with a fresh Ubuntu install all updated could I get configuration help via Skype and teamviewer? Rgds, Pac-Man Sent from ProtonMail Mobile

3 2