- tor-relays - lists.torproject.org

relay got suspended
by Paul Geurts 26 Oct '20

26 Oct '20

hi y'all, one of my relays got suspended today, because of heavy ddos traffic. *Hello,* *Today your VPS IP address was heavily attacked by a large DDoS, so we were forced to suspend the VPS and null the IP for the time being, since it had overloaded our upstream provider. We are keeping an eye on the situation, however in the meantime you will want to get your site behind a DDoS filter such as CloudFlare.* *Let us know if you have any further questions.* *Thank you!* *Adam* has any of you see this behauvior? I think there is no use in putting a relay behind a ddos filter, or is there? In that case I'll just spin up another one. relay in question is this one, almost 7 months with no interuption what so ever, no indication in the (munin) monitoring for high or higher traffic... because the vps is suspended I don't have the latest syslog so I don't know for sure whether anything has shown up there, but I am quite sure that yesterday there were no abnormal logging entries on this server. https://metrics.torproject.org/rs.html#details/CDE4149F0DC65A7BE1AE440340BE… rgds,. Paul

4 3

FreeBSD and Libressl from the ports
by Felix 26 Oct '20

26 Oct '20

Hi everybody :: That post went as well to tor-bsd(a)lists.nycbug.org but is reposted here for a potential higher attendance :: This is for those who run FreeBSD and Libressl from the ports. Because of the issue [0] we can not compile from source. Maybe you can use Libressl from the base system or you overwrite the security/libressl or security/libressl-devel port with an older version like 3.2.0 and compile from there. (Uhh, you can go with Openssl until the fix is in place) Please find the ports files in [1]. Libressl 3.2.0 works with Tor 4.4.x like a charme. Libressl 3.2.1 and 3.2.2 cause an issue with some Tor auths. Libressl 3.2.2 is/was devel and sits as well in non-devel, so we can not switch back this time :( . [0] https://gitlab.torproject.org/tpo/core/tor/-/issues/40128 [1] https://svnweb.freebsd.org/ports/head/security/libressl/ -- Cheers, Felix

1 0

My Tor exit node not visible
by netaudit 21 Oct '20

21 Oct '20

Hi there, I've set up a new Tor exit node around 15 hours ago but despite it had been such a time and my exit is visible from outside world I still get little to no traffic at all. I also cannot see my servers IP on bulk tor exit node list. I checked the logs and everything seems alright too: [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Can you please tell me what I am missing here? Thank you Sent with [ProtonMail](https://protonmail.com) Secure Email.

6 6

ContactInfo Spec Version 2 is released
by nusenu 20 Oct '20

20 Oct '20

Hi, I'm happy to announce version 2 of the ContactInfo Information Sharing Specification. https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/ It comes with an easy to use ContactInfo generator, which is maintained by Eran Sandler: https://torcontactinfogenerator.netlify.app/ Example ContactInfo string as defined by this specification: email:tor[]example.com url:https://example.com proof:uri-rsa uplinkbw:100 ciissversion:2 In words this ContactInfo string means: - the technical contact for this relay can be reached at tor(a)example.com - the entity responsible for this relay has a website at https://example.com - the proof file to verify the url can be fetched from https://example.com/.well-known/tor-relay/rsa-fingerprint.txt - this tor instance can provide a bandwidth up to 100 Mbit/s - this string implements version 2 of this specification The spec has many fields to choose from but I'd like to highlight these 3 fields, also used in the example above, as some of the most relevant: - email - url - proof The proof field allows operators to make their URL value verifyable (protected against spoofing) by placing their relay fingerprints in a text file located on their website. If no website is available DNS TXT records can be used instead. Now that version 2 is out, we will work on parsing to provide operators with an easy way to check their strings (and maybe also their proofs) interactively. I intend to use the data as input for OrNetStats as operators start to set their ContactInfo strings. I have operator-level graphs in mind, showing the operator how his set of relays evolved over time. See https://raw.githubusercontent.com/nusenu/tor-network-observations/master/pn… for an example. The timespan will likely be significantly smaller than the one used in this example. The release of version 2 marks the deprecation of version 1. I aim to support version 2 for at least 2 years and aim to make future releases backward compatible. I've no plans to significantly change or extend the amount of fields, with the exception of one potentially interesting use-case (see the bottom of this email). Many changes that went into version 2 are directly related to your comments after publishing version 1, thanks for that! We also got feedback for the generator and are tracking them here: https://github.com/erans/torcontactinfogenerator/issues Changelog ---------- Most notable changes since version 1: - 'operatorurl' got renamed to just "url" - "verifyurl" field simplified/replaced with "proof" (no longer requires a webserver) - email field is no longer mandatory - UTF-8 support - xmr (monero) field added - bitcoin field renamed to btc - zcash field renamed to zec - PGP keys should be on keys.openpgp.org (verifying keyserver) - removed fields: KIST, ricochet Future Idea Since some had concerns about spam: It would be trivial to add support for an encrypted email address when the operator has a webserver and a verified url field. If there is some demand for this and the Tor Project is willing to publish a GPG key that can be used for encryption I'll add support for it. That would mean only the persons at the torproject having access to that key could fetch the encrypted address and decrypt it with their private key, others would only see "encemail:y" or similar. kind regards, nusenu

3 2

Collaborative Bad-Abuse-Sender Blocklist
by Matt Corallo 19 Oct '20

19 Oct '20

Hi all, I run a few relatively-small exit nodes, and still get a decent flow of the usual Fail2Ban, blocklist.de, and such garbage to abuse PoCs. I tend to proactively find appropriate abuse/noc contacts to provide a response informing them of how they can appropriately block all Tor exits from their SSH ports if they wish, but often get either no or indignant responses about how sending a stream of garbage abuse reports is a useful service to the internet (nevermind that most large providers don't bother handling abuse reports anymore because of exactly this behavior). After a reply or two I usually add senders to a blocklist and bounce them at the mailserver with a notice about spam not being useful. Is there any interest in building up a shared blocklist of senders who feel its their right to send Fail2Ban emails in non-machine-parsable formats and not bother handling replies to their emails they expect others to handle, or does anyone already have such a list? Matt

4 6

Help setting up 2 Relays
by postmaster＠coolcomputers.info 18 Oct '20

18 Oct '20

Hello, I was wondering it anyone more experienced could help me with fixing 1 TOR Exit and 1 TOR Relay. I have everything configured and fingerprints made they just seem to not me recognized by tor metrics. Tor Relay: B0852A98ECDB40E95319DEE339662EEF50708066 Tor Exit: A5D03FC9BE6EE32BD20EE59649BAD802BF4A49FC There is nothing in the notice logs as to why this would be happening. Maybe someone can see what the DA's think of them. Then give me advice on what to do. Thanks, John Csuti postmaster(a)coolcomputers.info

5 6

Network Performance Experiment - KISTSchedRunInterval - October 2020
by David Goulet 17 Oct '20

17 Oct '20

Greetings relay operators! Tor has now embarked in a 2 year long scalability project aimed, in part, at improving the network performance. The first steps will be to measure performance on the public network in order to come up with a baseline. We'll likely be adjusting circuit window size, cell scheduling (KIST) and circuit build timeout (CBT) parameters over the next months in both contained experiments and on the live network. This announcement is about KIST parameters, our cell scheduler. Roughly a year ago, we've discovered that all tor clients are capped to ~3MB/sec in maximum outbound throughput due to how the scheduler is operating. I won't get into the details but if you are curious, it is here: https://gitlab.torproject.org/tpo/core/tor/-/issues/29427 It turns out that we now believe that the entire network, not only clients, are actually capped at 3MB/sec per channel (a channel is a connection between client -> relay or relay -> relay also called an OR connection). We've recently conducted experiments with chutney [1], which operates on the loopback interface, and we indeed hit those limits. KIST has a parameter named KISTSchedRunInterval which is currently set at 10 msec and that is our culprit. By lowering it to 2 msec, our experiment showed that the cap goes from 3MB/sec to ~5MB/sec with burst a bit higher. Now, the question is why was it set to 10 msec in the first place? Again, without getting into the technical details of the KIST paper[2], our cell scheduler requires a "grace period" in order to be able to accumulate cells and then prioritize over many circuits using an EWMA algorithm which tor has been using for a long time now. Without this, one can clog the pipes (at the TCP level) with a very loud transfer by always being scheduled and filling the TCP buffers leaving nothing for the quieter circuit. Important to note that the goal of EWMA in tor is to prioritize quiet circuit for example, an SSH session will be prioritized over a bulk HTTP transfer. This is so "likely" interactive connections are not delayed and are snappy. But, lowering this to 2 msec means less time to accumulate and in theory worst cell prioritization. However, we think this will not be a problem because we believe the network is underloaded. And, because of this 3MB/sec cap per channel, it means that tor is sending burst of cells instead of a constant stream of cells and thus it is under processing what it possibly could at the relay side. Again, all this in theory. All in all, going to 2 msec should improve speed at the very least and not make the network worst. We want to test that, measure that for a couple of weeks and then transition to a higher value and doing that until we get to 10 msec so we can clearly well compare the effect on EWMA priority and performance. One possibility will be 2 msec, 5 msec, 10 msec transition period. Yesterday, a request to our 9 directory authorities have been made to set this consensus parameter: KISTSchedRunInterval=2 We are still missing 1 authority to enable this param for it to take effect network wide. Hopefully, it should be today in the coming hours/day. This is where we need your help. We would like you to notify us on this thread about any noticeable changes in CPU, RAM, or BW usage. In other words, anything that changes from the "average" you've been seeing is worth informing us. We do NOT expect big changes for your relay(s) but there could reasonably be a change in bandwidth throughput and thus some of you could see a traffic increase, unclear at the moment. Huge thanks to everyone here! We will carefully monitor this change and if things go bad, we'll revert it as fast as we can! Thus, your help becomes extremely important! Cheers! David [1] https://git.torproject.org/chutney.git/ [2] https://arxiv.org/pdf/1709.01044.pdf -- 7h1/NAPdaaGpI8WG6X4FtryAZZ4EhnznUVVLqIf/04A=

6 10

Shutdown of my digital ocean guard relay
by mick 16 Oct '20

16 Oct '20

Hi Guys I today received notification from DO that they have changed their Terms of Service and Acceptable Useage policies. Having read those changed notices it is clear to me that DO are no longer really Tor friendly. They do not allow exits and whilst my guard relay there (at roof.rlogin.net with fingerprint EA8637EA746451C0680559FDFF34ABA54DDAE831) has been running for nearly seven years I can no longer do that because of the likely bandwidth charges in future. My DO relay has been using around 12 TiB per month for some time now and I could afford to let it run because I was a "legacy" customer (i.e. early adopter of DO services who was given "free bandwidth forever"). It looks to me from their new ToS that I will no longer enjoy that status after 22 October. So I have shut it down. Any other relay operator using DO services should read their new ToS (1) and AUP (2) and decide for themselves whether they will be affected. My other guard relay at sink.rlogin.net on Hetzner's network will continue in operation. Mick (1) https://www.digitalocean.com/legal/terms-of-service-agreement/ (2) https://www.digitalocean.com/legal/acceptable-use-policy/ --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 https://baldric.net/about-trivia ---------------------------------------------------------------------

6 10

Is this next bad exit trick?
by lists＠for-privacy.net 14 Oct '20

14 Oct '20

Wtf, this exit has addresses that do not belong to it! https://metrics.torproject.org/rs.html#details/385527185E26937D05E0933DD29F… I'm very sure there are only nifty rabbits on the 185.220.101.0/24 subnet! -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

6 14

Relay JPsi2 not getting into consensus anymore
by Random Tor Node Operator 14 Oct '20

14 Oct '20

Hi all, some weeks ago, my relay JPsi2 (F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521) started experiencing moderate stability problems. It would freeze after a few hours or days. The provider said it was due to Spectre mitigations and the only way for me to fix this would be to switch to a newer (more expensive) plan... Some time later I did so and reinstalled it with Ubuntu 18.04 and placed the old keys into the new installation. It seems they are now expected to be in /var/lib/tor/.tor/keys, as opposed to /var/lib/tor/keys as I was used to in Ubuntu 16.04. However, it does not seem to be making it into the consensus anymore. Only the authority nodes moria1, dizum, and longclaw vote for Running. The others don't. So far I haven't been able to figure out the reason for that, so any help is appreciated. Here is part of the output of journalctl -u tor and the torrc file: Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Heartbeat: Tor's uptime is 8 days 0:00 hours, with 0 circuits open. I've sent 54.04 MB and received 163.30 MB. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] While bootstrapping, fetched this many bytes: Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 9368438 (server descriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 1060775 (consensus network-status fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 13332 (authority cert fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 2762395 (microdescriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] While not bootstrapping, fetched this many bytes: Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 111548029 (server descriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 100899 (server descriptor upload) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 15307429 (consensus network-status fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 1785 (authority cert fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] 942746 (microdescriptor fetch) Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Average packaged cell fullness: 96.710%. TLS write overhead: 31% Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Circuit handshake stats since last time: 1/1 TAP, 0/0 NTor. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 2 v2 connections; initiated 0 and received 114 v3 connections; initiated 0 and received 1899 v4 connections; initiated 46 and received 5694 v5 connections. Oct 11 15:04:32 j60204.servers.jiffybox.net tor[11183]: Oct 11 15:04:32.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Oct 11 18:14:03 j60204.servers. # cat /etc/tor/torrc OfflineMasterKey 1 SOCKSPort 0 SOCKSPolicy reject * RunAsDaemon 1 ControlPort 9051 HashedControlPassword 16:28CD63819CB35660601EB9CED4BC2A4252D3DB80488DFD4F22CA4AE930 ORPort 9001 ORPort [2a00:1158:3::1ba]:9001 Nickname JPsi2 RelayBandwidthRate 12500 KB RelayBandwidthBurst 12500 KB ContactInfo 0xF1ADC390 Random Tor Node Operator <tor at unterderbruecke (dot) de> bitcoin:1LBoEppezy2HauE957HzfFn9UGywK6aboB DirPort 9030 MyFamily $B198C0B4B8C551F174FBB841A172616E3DB3124D, $F6EC46933CE8D4FAD5CCDAA8B1C5A377685FC521 IPv6Exit 0 ExitPolicy reject *:* ExitPolicy reject6 *:*

3 3