March 2018 - tor-relays - lists.torproject.org

Please use mailing lists for questions
by teor 28 Mar '18

28 Mar '18

Hi, In the past few weeks, at least 5 relay operators have emailed me directly to ask questions. I haven't answered most of those emails, because I was on leave, then at a meeting, then on leave again. I won't have time to check all my backlog for another 1-2 weeks. If you want a quick answer to your question, use a mailing list. If it doesn't matter who answers your question, use a mailing list. If your answer contains private information, redact it, then use a mailing list. If your question can only be answered by a single person, then use a mailing list, so other people can learn the answer. Please try really hard to use a list. Emailing a single person doesn't scale. And please don't feel hurt if someone asks you to use a list. It means your question is valuable to other people. T

1 0

Decommissioning (middle) relay
by tor-relays 27 Mar '18

27 Mar '18

In case anyone is keeping an eye on things or otherwise monitoring relays, I have just decommissioned the relay "wsmith6079" (with fingerprint 01AE002B4E60AE5A8FF40FDB67260F85AB0878AE) within the last several minutes. This relay has been in service for a little over two years but, unfortunately, it's time has come. Thanks.

2 1

My relay lost concensus
by victoring＠riseup.net 27 Mar '18

27 Mar '18

Hi, After a power cut a couple of weeks ago, my tor relay is not longer part of the consensus: B33BFA9AA0005730C1C0E8F7E6F53CF3C5716BD6 Current tor process has been running since 2018-03-14. How much time is it needed to come back? Cheers, S

2 4

arm crashes
by smichel0 26 Mar '18

26 Mar '18

Hello, from time to time, arm looks like below: https://smichel.ocloud.de/index.php/s/q2knnq3AD67rPjK But with a simple keystroke (arrow) it runs again. After a few days it seems to crash completely: https://smichel.ocloud.de/index.php/s/GjwdCLebR4iDkuv I dont't know then, if the relay is still working. Last time this happend, I simply startet arm again and it worked. But thiis way I will never reach the guard-flag :) Yours SMichel Sent with [ProtonMail](https://protonmail.com) Secure Email.

5 18

relayor v0.3.3 is released
by nusenu 26 Mar '18

26 Mar '18

Hi, relayor v0.3.3 is released. relayor helps you with running relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor Changes since v0.3.2: ------------------------------ - major workaround for an upstream bug in tor that prevented us from running more than 2 instances per server. This affected only users with a non-default tor_maxPublicIPs setting. (#153) Thanks to Tim Niemeyer (@RedDog99) (f3netze.de) for bringing this to our attention. - relayor now ships a kitchen file for integration testing (#149) Thanks to Ondrej Vaško (@Lirt) for the patch. Main benefits for a tor relay operator ====================================== * automation - no more manual setup tasks * security: offline Ed25519 master keys every tor instance is run with a distinct user * automatically makes use of IPv6 IPs (if available) * automatic tor instance generation (two by default - configurable) * enables tor's Sandbox feature by default on Debian-based systems * easily choose between alpha/non-alpha releases * easily restore a relay setup * easily choose between exit relay/non-exit relay mode * automatic deployment of a tor exit notice html page via tor's DirPort * automatic MyFamily management Supported Operating Systems ---------------------------- Debian 8, 9 and Debian Testing OpenBSD 6.2 FreeBSD 10.4, 11.1 HardenedBSD 11 Ubuntu 16.04 CentOS 7 Fedora 27 regards, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 1

Hello new exit operator F3 Netze
by nusenu 25 Mar '18

25 Mar '18

Hello F3 Netze, I saw you recently added 8 new tor exit instances and wanted to thank you for contributing exit bandwidth to the tor network! Should there arise questions related to the operations of tor relays you can reach out to the public tor-relays mailing list [0]. Your AS information is not yet in Maxmind's databases so it does not show yet on Relay Search [1] pages but this will solve itself over time. I saw your have IPv6 addresses [2]. If your connectivity/routing allows also for IPv6 exiting and ORPorts, enabling IPv6 on your exits would be great and appreciated. Looking at your ORPorts and your perfect MyFamily configuration this looks like an ansible-relayor setup, in which case IPv6 will be automatically enabled on the next playbook run once the servers have IPv6 addresses (if you didn't opt-out). thanks for joining the network and happy packet forwarding! nusenu [0] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays [1] https://metrics.torproject.org/rs.html#search/family:6BCB964AB74E23F8986BDA… [2] https://bgp.he.net/AS205100#_prefixes6 -- https://mastodon.social/@nusenu twitter: @nusenu_

3 7

Publishing bridge contact information
by Karsten Loesing 23 Mar '18

23 Mar '18

Hello relay and/or bridge operators, you might already know this: we're publishing sanitized versions of bridge descriptors on Tor Metrics. https://metrics.torproject.org/collector.html#bridge-descriptors We're using these sanitized descriptors to visualize interesting facts about Tor bridges, among other things: https://metrics.torproject.org/bridges-ipv6.html We're now considering to drop one step in the sanitizing step, which is to remove contact information. The result would be that we'd keep contact information in sanitized descriptors in the exact same way as the bridge operator put it into their torrc file. https://metrics.torproject.org/bridge-descriptors.html#contact https://trac.torproject.org/projects/tor/ticket/20983 Possible advantages are: - Relay Search would support searching for bridges by contact information. - People who keep a watching eye on the Tor network could reach out to bridge operators to inform them that they're running an outdated tor/PT version, or that running bridges and exits together is not cool. - If somebody ever revives OnionTip/TorTip, bridges could participate and receive donations for running a bridge. Or t-shirts, who knows. Note that I'm not promising either here, but without contact information, neither would even be possible. Possible disadvantages are: - If somebody runs a relay and a bridge, both with the same contact information, a censoring adversary might guess that the bridge might run on a nearby IP address as the relay. However, they could as well assume that for all relays and block or scan the IP space around all known relays. - Bridge operators might be surprised to see their contact information in a public archive. We do have a warning in the tor manual https://www.torproject.org/docs/tor-manual.html.en#ContactInfo, but maybe nobody reads the fine manual. Your opinion counts. Is this a good or a bad idea, and why? I'll keep this discussion open for a week and not start changing anything during that time. If you want to state your opinion, please do it on this list by Wednesday, February 14. Thanks! All the best, Karsten

8 21

DoSer is back, Tor dev's please consider
by starlight.2017q4＠binnacle.cx 23 Mar '18

23 Mar '18

Please note: Here parameter DoSCircuitCreationMinConnections=1 is set (rather than the default value of 3). Mar 11 17:23:53 Tor[]: DoS mitigation since startup: 0 circuits rejected . . . . . . Mar 22 11:23:54 Tor[]: DoS mitigation since startup: 299608 circuits rejected. . . Mar 22 17:23:54 Tor[]: DoS mitigation since startup: 806025 circuits rejected. . . I.E. mitigation circuit rejections increased 170% in six hours after moving vaguely for over ten days. Also: top - 19:05:53 up 11 days. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1998 tor 20 0 662m 611m 108m R 47.2 15.4 7901:32 tor 2000 tor 20 0 662m 611m 108m S 42.2 15.4 343:28.28 tor 2001 tor 20 0 662m 611m 108m R 56.8 15.4 343:24.46 tor I.E. crypto workers pegged after barely registering since DoSer shut it down on March 7th. 'iptables' mitigation rule here shows the DoS source-IPs ablaze. ========== Suggestion: DoSCircuitCreationMinConnections=1 be established in consensus

3 3

Re: [tor-relays] Previous Guard not getting Guard flag back
by starlight.2017q4＠binnacle.cx 23 Mar '18

23 Mar '18

>While I understand that my relay lost the guard flag because of a weekend >of downtime, I would expect that it would get it back after a while of >stable again? Anyone able to shed some light on when it will get the flag >back? >https://metrics.torproject.org/rs.html#details/924B24AFA7F075D059E8EEB284CC… Guard flag calculation is somewhat involved (due to several get-out-jail promotions/bypasses), but the essential part is weighted uptime in excess of the median uptime of guard candidates, or 98% whichever is lower. Presently the authorities have it somewhere around 96% (they do not publish the value). Your relay is at about 91% and will be back as a Guard in less than five days when it will hit 97%. The attached XLS shows it roughly, left side today and right side as-of 3/26. Uptime data came from the "1_month" section of https://onionoo.torproject.org/uptime?search=NSDFreedom Built this sheet for myself recently and simply stuffed in data for your relay. Enjoy. P.S. If anyone spots flaws in the approach, please comment.

1 5

tor-instance-create vs. /etc/tor/torrc
by Igor Mitrofanov 22 Mar '18

22 Mar '18

Hi, I use tor-instance-create to spawn a number of relay instances. However, there seems to be one extra instance running - the default one that reads /etc/tor/torrc (and not /etc/tor/instances/INSTANCE/torrc). How do I disable that default tor relay? It opens port 9050 and does who else knows what by default. I can delete /etc/tor/torrc and it seems to do the trick, however, I am not sure how permanent this change will be with automatic package updates. Thanks!

4 3