tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

Encrypting the DataDir
by Cristian Consonni 31 May '17

31 May '17

On 15/05/2017 12:21, aeris wrote: > Private key are under encrypted volume and may be protected On 21/05/2017 10:02, Roger Dingledine wrote: > On Sun, May 21, 2017 at 09:12:39AM +0200, Petrusko wrote: >> @aeris, do they ask you to uncrypt the volume ? (good luck to you...) >> What can be the best ? Uncrypt the relay to help police when asking, >> when this relay is only a relay and storing nothing else ? > > That's actually why the torservers.net people suggest *not* using disk > encryption. Having no barriers makes it much easier for the police to > realize that there's nothing useful to them. See also point two of > https://blog.torproject.org/blog/trip-report-tor-trainings-dutch-and-belgia… >From the Tor Exit Guidelines: «Disk encryption might be useful to protect your node keys, but on the other hand unencrypted machines are easier to "audit" if required. We feel it's best to be able to easily show that you do Tor exiting, and nothing else (on that IP or server).» https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines I was wondering if the argument about not encrypting the disk applies just to the full-disk encryption or if it is applicable also to the caso of encrypting just the DataDir on a fairly small file-based volume (say 100MB). In the second case, how big can the DataDir get? Cristian

5 6

reminder: tor 0.3.1.1-alpha is _not_ recommended (known bug)
by nusenu 31 May '17

31 May '17

Since there were only 8 relays running 0.3.1.1-alpha I didn't bother to state this here, but since the number is rising since yesterday I just wanted to remind you that tor 0.3.1.1-alpha contains a bug that makes this not a good version to use. In the worst case (unlikely) you would publish a limited amount of memory via your relay descriptor https://trac.torproject.org/projects/tor/ticket/22368#comment:7 https://trac.torproject.org/projects/tor/ticket/22378 Relays currently using tor 0.3.1.1-alpha (excluding Roger's): +------------------+------------------------------------------+ | nickname | contact | +------------------+------------------------------------------+ | Quincy | NULL | | ss666 | NULL | | sorryitsslow | NULL | | artiX | NULL | | ELECTRICSHEEP | NULL | | dahool | NULL | | BabylonNetwork01 | Babylon Network | noc <AT> babylon <DOT> | | BabylonNetwork03 | Babylon Network | noc <AT> babylon <DOT> | | BabylonNetwork00 | Babylon Network | noc <AT> babylon <DOT> | | BabylonNetwork02 | Babylon Network | noc <AT> babylon <DOT> | | Gentoo | gentoo.intel(a)gmail.com | | 0x000000000 | https://ban.ai | | HeirloomReaper | James Taylor <tor AT fornoreason dot net | | ireadconf | torrelay(a)fh-biergarten.de - 1QCHdyhPHLrK | +------------------+------------------------------------------+ If you are eager to run alpha level tor versions to uncover and report bugs early that is great but you might want to wait for tor 0.3.1.2-alpha or run master builds after https://gitweb.torproject.org/tor.git/commit/?id=ab9976b7245f05a97e0285265c… https://deb.torproject.org/torproject.org/dists/tor-nightly-master-stretch stay safe, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 3

Question about circuit/path live time
by Olaf Grimm 31 May '17

31 May '17

Dear readers ! For my relays I looking for a torrc parameter to reduce the circuit live time from default of 10 minutes to about 5 minutes. My intension: I dont' know is the point of time to switch the path between relays synchronized. An overlap (or different switching time) will reduce the path live time to less than 10 minutes. This is ok for me, because the circuit analysis time for attackers is less than 10 minutes (traceroute...). Synchronized relays keeps a whole circuit path open for 10 minutes, from guard to the exit. Am I right? Am I right with my intension to change the default circuit live time or is this not necessary? A short answer would be ok. Assuming torrc parameter: MaxCircuitDirtiness NUM (Default: 10 minutes) The backgroud of the story (and why I want to generate more noise): Last year, on July 19, my exit relay was seized at home. I knew about the danger, but I ignored it. According to the police, my relay was abused for about 5 months, again with the same (evil) web server as the target. I am assuming my Exit Relay was explicitly selected as an exit. To protect the relay operators, you might want to remove this function. A targeted compromising of an operator must not be possible. The police photographed some of the current connections displayed with ARM. A test with ARM showed an indication of a seemingly complete circuit from the guard to the exit. I see Source -> Target, Guard, Middle, Exit. I'm not sure, but I get a bad feeling. Please tell me that my interpretation of the displayed content in ARM is wrong. For the time being, I only have 2 Middle nodes as VPS online. Later, after the completion of the law procedure, I switch the two VPS middle nodes back to Exit Relays (Provider Keyweb and FlokiNET). The third middle node at home remains only a middle node. I swear this. Best regards! Olaf (node49/node49a/node49b)

2 1

Neldoreth relay seized ?
by aeris 30 May '17

30 May '17

Dear Neldoreth relay’s operator, This day, we were informed of a Tor node seizure at FirstHeberg during the 13-14/05, related to Wanacry infection of the french company Renault. https://www.nextinpact.com/news/104398-wannacrypt-nud-tor-saisi-chez-firsth… FirstHeberg say the seized node was "traffic analyzed" during some times before being shuting down for content cloning and drive given to cops. They are at least 5 others relays seized under the same case at OVH and Online providers. https://www.nextinpact.com/news/104302-wannacrypt-nuds-tor-saisis-par-autor… https://gist.github.com/nusenu/3d7bbeb7c97af591d65003b4bfe70021/ After consensus investigation, it seems your Neldoreth node is the only hosted at FirstHeberg with a downtime during this timeframe (from 14/05 18:00 to 17/05 14:00). This node is currently running, but lost its guard flag since restart. Could you confirm if your node was seized or not ? If seizure confirmed or suspected, your private key is probably no more safe, so please report your fingerprint to bad-relays(a)lists.torproject.org for blacklisting to avoid reusage, and renew your private key. Regards -- Aeris https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/

3 2

New exit node best practices
by Isaac Grover, Aileron I.T. 29 May '17

29 May '17

Good evening, After many months of running a relay, I'm planning to establish up a family of exit nodes with geographically diverse VPS providers, shying away from the list of the most heavily used Tor friendly providers. Several questions: - Does establishing a family increase the risk of the nodes being taken down en masse? - Do you suggest providing ample contact information for the node directory, as opposed to little or none? - I'm being very upfront with sales@ regarding my purpose before signing up, and making sure they're okay with it. What questions should I be asking to be sure they'll be Tor friendly before shutting down my exit nodes? Make your day great, Isaac Grover, Senior I.T. Consultant Aileron I.T. - "Practical & Proactive I.T. Solutions" O: 715-377-0440, F:715-690-1029, W: www.aileronit.com

5 4

Memory Problems with tor releay
by tor-relay.dirk＠o.banes.ch 27 May '17

27 May '17

Dear all, we are operating two exit nodes with each two tor processes out of Switzerland. The nodes worked quite stable until about 2-3 weeks ago. Since then we experience frequent disruptions (Up to several times a day). This is caused by a significant rise in memory consumption by the tor processes and ends with a tor process being killed by the Linux Kernel: May 22 00:30:43 tor2 kernel: [2257156.134100] Killed process 40964 (tor) total-vm:448088kB, anon-rss:0kB, file-rss:0kB The systems are physical machines with Ubuntu 14.04.5 LTS with 4 GB of memory. This was sufficient the last 2 years. For more details a sample of this behavior is documented in a Ticket [1]. Tor project team is researching but until now no hints lead to an improvement. Due to a tweet last week [2] and the follow up discussion with another operator I became suspicious that is not just just us having a problem rather it cloud be more common. Therefore here the question to you all - do you experience some strange behavior like described in the ticket as well ? Please let me know if so. If not - maybe it is just an unfortunate coincidence and we will end up make a clean install of both server hoping the problem will go away. best regards Dirk [1] https://trac.torproject.org/projects/tor/ticket/22255 [2]https://twitter.com/FrennVunDerEnn/status/864583496072876034

10 15

neel@neelc.org relays: MyFamily and tor version update needed
by nusenu 26 May '17

26 May '17

Hi Neel, thanks for running FreeBSD tor relays. Your new relay added yesterday is not yet in sync with your other relays yet, please consider updating the MyFamily configuration to help protect tor clients from using a single operator in entry and exit position: https://atlas.torproject.org/#details/0D8211D34F29F51D690303E319766E1B7C28B… https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#neel-chauha… You also might want to update these relays running a tor version that is vulnerable to TROVE-2017-002: https://atlas.torproject.org/#details/1602E42D1DE3C7B3EF042F357F906DE55FA6C… https://atlas.torproject.org/#details/D5B8C38539C509380767D4DE20DE84CF84EE8… tor 0.3.0.7 contains the fix for TROVE-2017-002 and can be installed via FreeBSD's pkg command. thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

1 0

exit relay consensus weight
by Arisbe 26 May '17

26 May '17

Hello relay ops, I just made an interesting observation that I thought I would share. Yesterday I started a VPS exit relay at a well known hosting company in Moldova [0]. Within 24 hours I saw the consensus weight exceed 10000. The relay is bandwidth limited to 10 MiB/s. Not that I'm complaining! So it begs the question: Is there not enough exit relays on the Tor network? Arisbe [0] B06F093A3D4DFAD3E923F4F28A74901BD4F74EB1

2 1

Legal Status of Relays Worldwide [was: kittens seized]
by grarpamp 25 May '17

25 May '17

>>> That's actually why the torservers.net people suggest *not* using disk >>> encryption. Having no barriers makes it much easier for the police to >>> realize that there's nothing useful to them. >> This falling over may perhaps not be preferred by operators who like to >> create wins in the crypto war. You want police to go get their warrants, >> waste their time and money, just to prove nothing upon decrypt... >> then you have higher recorded, thus marketable, percent of nothing >> found among all forced decrypt cases. Instead of closer to 100% >> of such cases just confirming already forgone criminal cases. >> Having higher barriers and costs and demonstrably less fruit >> ratio can make such seizures more unlikely in first place. > Can they force an operator to decrypt, if he lives in other country > which is non-US and non-EU (e.g. Russia or China)? Depends if hosting country can extradite, or threat influence at things of value such as bank accounts, travel bans, people, etc. > Does it make sense > to run nodes in countries you don't live in or visit? If poor odds or afraid of such things, the farther distant and / or opposite legally, politically, logically and physically the better. > What happens if an operator themselves is anonymous? They lose the remaining hosting contract worth of bitcoin, get the account / card canceled, nym blacklisted, etc. For only running an exit / relay and nothing else... Policy / nuisance shutdowns by the hoster do happen often, nodes just move and redeployed elsewhere. Detainer for questioning, are rare, oops, you're free to go. Raids and confiscation, are rare, and property seems to be returned. Actual arrests / night in jail / charges, are even rarer, oops you're free to go. Charges that go to court, are extremely rare. Probably no one has *ever* been convicted that we know of? Because only running an exit / relay and nothing else, seems to be legal everywhere. (If it is illegal somewhere, then the operator is at fault for breaking that law.) And traffic passing through relays seems to have "ISP style" legal exceptions everywhere, that even cover "torts", so long as operators are not in business of inspecting or moderating. Which is why everything above is marked "rare". If you know of places where... a) relays themselves are illegal or b) ISP style exceptions do not exist ... you should definitely reply with such a list. Real problems are rare, and running relays is fun :) Legal environments typically apply equally so once you know your environment you can always add other overlay networks / services / nodes into to the mix if you're bored or have unused bandwidth in your contract: I2P, CJDNS, GNUNet, Freenet, Pond, VPNGate, XMPP / IRC, Remailers, Crypto Currencies, IPFS, etc...

4 4

Upgrading a relay and changing IP address
by Cristian Consonni 25 May '17

25 May '17

Hi, On 18/05/2017 01:56, Gunnar Wolf wrote: > Cristian Consonni dijo [Wed, May 17, 2017 at 05:04:29PM +0200]: >> AS you can see from the Debian package page[1] the latest available >> version of Tor packaged for Wheezy is 0.2.4.27-3, which to me looks >> quite behind either 0.2.5.12-4 available in Jessie (stable) or the >> 0.2.9.X series available through backports or testing. >> >> What's the best to do in this cases? >> * Should I start updating tor manually? >> * Should I update Debian on the server? (which could well me start with >> a fresh install? >> * Is it ok like it is now, provided that the system is updated? > > While Debian Wheezy (7, our "oldstable" release) still has security > support via LTS¹, it is not recommended to run a Tor relay with such > old packages. In fact, not even the version available in Jessie (8, > our "stable" release - 0.2.5.12-4) is recommended nowadays. > > I suggest you to update to _at least_ Jessie and use the version in > backports (depends on your sysadmining, but if your machine's only use > is to run a Tor node, I'd suggest installing Stretch, 9, which has > 0.2.9.9-1). I am running the relays on VPS providers so, I can choose (only) among the versions of Debian that are provided by the services as templates. When Stretch is release I will see if they make it available, in a reasonable time. I am settled anyhow to upgrade the nodes as soon as the new Debian version is released and I have a question. I have read that I can move the node keys when upgrading[1] and I will do that. One thing that will change with a fresh install is the IP address of the nodes. So, I was wondering, in general is a good thing to keep the same IP or changing it? Because in any case, I could try and do a dist-upgrade[2] so that I keep the old IP. I have also discovered now that DigitalOcean, one of the providers I use, provides a kernel-management interface[3] that could make the process easier. So, which is preferable between the two processes where one has the advantage of keeping the same IP (dist-upgrade) and the other not (fresh install)? Of course, I am assuming that I will be able to complete any of the two processes successfully. Cristian [1]: https://www.torproject.org/docs/faq.html.en#UpgradeOrMove [2]: https://www.debian.org/releases/stable/amd64/release-notes/ [3]: https://www.digitalocean.com/community/tutorials/how-to-update-a-digitaloce…

5 9

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays