tor-relays February 2018

tor-relays@lists.torproject.org

72 participants
67 discussions

new warning with Tor 0.3.4.0-alpha-dev (git-efc105716283bbdf)
by Toralf Förster 10 Apr '18

10 Apr '18

This happenes here now with that version usually once a day. Feb 19 18:59:00.000 [warn] Our clock is 1 minutes, 1 seconds behind the time published in the consensus network status document (2018-02-19 18:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! Feb 19 18:59:00.000 [warn] Received microdesc flavor consensus with skewed time (CONSENSUS): It seems that our clock is behind by 1 minutes, 1 seconds, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. -- Toralf PGP C4EACDDE 0076E94E

4 4

ansible-relayor, how to ?
by Petrusko 01 Apr '18

01 Apr '18

Hey! I'm planning to try the "ansible-relayor" to deploy some Tor relay instances. If I'm not wrong, it's a main goal ? 2 instances / IP... (soooory for being really noob about this!!!) But I'm lost... not found a tutorial, step by step, you know the tutorial so loved by all noobs! For now, on a fresh Debian8 install, there are : - tor 0.2.9.8 (fresh install from depo, client is ok when opening log file) - ansible - ansible-galaxy install nusenu.relayor - git clone https://github.com/nusenu/ansible-relayor (the folder is stored in my /home...) Will it configure (automatically) many torrc file per instance ? +every key files /relay ? (I'm not too much lost!) Do have I to do this install on every server built ? Or relayor can manage few servers on different locations ? Command lines list use this tool if available ? Many thx for help !!! (and hard work for this tool :) -- Petrusko C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5

6 9

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

Experimental DoS mitigation is in tor master
by Roger Dingledine 11 Mar '18

11 Mar '18

Hi folks, Thanks for your patience with the relay overload issues. We've merged https://bugs.torproject.org/24902 into tor git master. We'll be putting out an 0.3.3.2-alpha release in not too long for wider testing, and eventually backporting it all the way back to 0.2.9, but if you're the sort who enjoys running code from git, now is a great time to try it and let us know of problems and/or successes. Here's the changelog stanza: o Major features: - Give relays some defenses against the recent network overload. We start with three defenses (default parameters in parentheses). First: if a single client address makes too many connections (>100), hang up on further connections. Second: if a single client address makes circuits too quickly (more than 3 per second, with an allowed burst of 90) while also having too many connections open (3), refuse new create cells for the next while (1-2 hours). Third: if a client asks to establish a rendezvous point to you directly, ignore the request. These defenses can be manually controlled by new torrc options, but relays will also take guidance from consensus parameters, so there's no need to configure anything manually. Implements ticket 24902. To repeat that last part: there are a bunch of torrc options you can use to tweak stuff, but you can leave it all at the defaults and it will read its instructions out of the consensus parameters: https://consensus-health.torproject.org/#consensusparams Woo, --Roger

12 22

FreeBSD 11.1 ZFS Tor Image
by Conrad Rockenhaus 10 Mar '18

10 Mar '18

Hello All, If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image that is fully configured and ready to run Tor. Right now it's an eight GB image, but I'm reducing the size by removing all of the extra stuff on it from the upgrade from FreeBSD 11 to 11.1. If you're interested in the image let me know. This image has been fully tested on OVH's Openstack infrastructure, so if you're interested in running it on their infrastructure, let me know and I can walk you through it, or you're more than welcome to host is within my cloud at cost (it's a low monthly rate and unlimited bandwidth). Regards, Conrad Rockenhaus

15 38

less than 3 bw auths available: self-measurement (with 10k cap in effect)
by nusenu 04 Mar '18

04 Mar '18

Hi, if your relays behave strangely in terms of bandwidth seen, than this might be due to the fact that there are less than 3 bw auth votes available. If you run a fast relay it is capped to 10k cw. This affects currently the 857 fastest relays. regards, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

6 8

[WARN] Your computer is too slow to handle this many circuit creation requests
by Vasilis 04 Mar '18

04 Mar '18

Hi, I see a number of warning log messages on a dedicated server: [WARN] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [27615 similar message(s) suppressed in last 60 seconds] The relay is running on a dedicated hardware with the following specifications: CPU: Intel(R) Xeon(TM) CPU 3.00GHz RAM: 6G Kernel: Linux 3.16.0-5-amd64 Tor version: 0.3.2.9 flags: Fast, Guard, HSDir, Running, Stable, V2Dir, Valid exit policy: reject *:* Setting the NumCPUs option to the actual number of CPUs (2) didn't help. Is this hardware really too old/slow to run a relay on one ethernet Gigabit link? Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162

2 4

memory requirements
by notatorserver 03 Mar '18

03 Mar '18

Hi, I have just setup a tor-relay and I am wondering if the resource requirements are still current: "A non-exit relay faster than 40MBit/s should have at least 1 GB of RAM."[1] My relay is sitting at ~2.77G currently. I set the option: MaxMemInQueues 6GB Just wondering if this is any cause for concern? I realize the utilization is less than the limit but I just don't remember relays I have run in the past using this much memory. Thanks [1] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 2

Upcoming security releases for Tor 0.2.9 and up.
by Nick Mathewson 01 Mar '18

01 Mar '18

Hi! This coming week, we'll be putting out new stable releases for 0.2.9 and later supported branches to fix a few security bugs. The highest-severity bug to be fixed is severity "medium". (See https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Securit… for information about how we rank security issues.) These releases will also backport the anti-DoS features from Tor 0.3.3. Relays and authorities should be sure to upgrade once packages are available; these issues are not high-priority for clients. best wishes, -- Nick

4 5

Unmeasured Flag
by Matthew Glennon 28 Feb '18

28 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So if I'm understanding this correctly, we're still having problems with a bw testing nodes and that is why my relay has the unmetered flag? -----BEGIN PGP SIGNATURE----- Version: Keybase OpenPGP v2.0.76 Comment: https://keybase.io/crypto wsBcBAABCgAGBQJalsdlAAoJEHIAmlM/NGGbpQcH/16WQLlMAAVzx4blIRV2bIJF Hwdyj4FFQ+Ms0hHhj1DwMkB6EMa11kogLA8k+NGim8QeF2Qyobd1lARUXjZdfbV5 s/L6JYYCO+PsJxJY2+nOU41HUps1w5zLfFy+ekxkVwsX8dXq+SVy06+1HXfjY2uT HJnIpkx9/IZWMjJzRv33ylIMDq4u0MltJr+4MRrb5rSn6+9pz9m4z6CeUKJbsiLh nE0YRblkRwfrlVCP3VTaaRyQdMUwWzKwnB9S8dtKGDKb+tYz4QduFuzBf1eGGrO7 cp9GeHiittyBSGylRWveQgbkzwXRGPuUGtabXutQRqGXDvanDtEroHg+hUP0SEw= =b7/2 -----END PGP SIGNATURE-----

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays February 2018