- tor-relays - lists.torproject.org

Using ContactInfo to publish additional relay properties in a standardized way (opt-in)
by nusenu 15 Oct '17

15 Oct '17

Status: WIP please send your comments until 2017-10-27 I'm writing this with the following motivation: - make it easier for current and future relay operators to find (rarely used) hosters for tor relays by increasing the information sharing between relay operators. -> help the tor network grow - improve geo- and autonomous system diversity on the tor network (more diverse is better) - collect additional (self-reported) relay metrics (for things like atlas [1] and OrNetStats [2]) https://atlas.torproject.org https://nusenu.github.io/OrNetStats exmples: How many - use tor's Sandbox? - run in OfflineMasterMode? - make use of KIST? - do auto-updates? This data could provide tor developers with information on how well tested/how much used new features (like Sandboxes) are before changing defaults. - improve the ability to contact relay operators (automatically) - make provided information machine readable - provide the foundation for an automated contactInfo verification bot mutually verified email addresses (and other contact options) could be displayed differently on atlas.torproject.org - make t-shirt delivery easier since contact information is potentially already verified - increase the ability to detect undeclared relay groups / make hiding relay groups harder - make hosting costs visible - potentially detect relay operators impersonating other operators by using their email address Should 10% cw fraction and at least 50 operators use any of the defined fields I'll ask irl (atlas maintainer) to get that specific field added to atlas (separately from the contactinfo string). Example ContactInfo String -------------------------- email:user[]example-operator.com hoster:https://example-hoster.com uplinkbw:100 trafficacct:unmetered cost:10 virtualization:xen Considerations ---------------- - increases exposure of relay operators The machine readable information could be used by spammers and to target relay operators. Operators concerned about this can omit contact information but it should not be hard to create a new email address for the purpose. - more information makes targeted exploitation easier / more silent Attackers could use the additional information provided in these fields to specifically target only vulnerable systems. Operators concerned about sharing configuration information should omit this type of information, but can share other information. - increased descriptor size and directory traffic The contactinfo field size could potentially grow because of this specification. This should be mitigated with the use of directory data compression and diffs available since tor 0.3.1. - ContactInfo size constraints According to the manual [2] there is no explicit ContactInfo size limit but there is a descriptor size limit. The max. descriptor size is 20000 bytes [3]. The family size and exit policy are two other relevant inputs. [2] https://www.torproject.org/docs/tor-manual.html.en#ContactInfo [3] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n364 List of information fields ---------------------------- I started to collect possible fields here: https://github.com/nusenu/ContactInfo-Information-Shareing-Specification#de… looking forward to your feedback, nusenu Document location: https://github.com/nusenu/ContactInfo-Information-Shareing-Specification -- https://mastodon.social/@nusenu twitter: @nusenu_

4 6

Relay DDoS attack?
by Peter Rogers 14 Oct '17

14 Oct '17

Hi! I've been running a Tor non-exit node at my business for a few months now. So far it's been great! Except yesterday when I noticed my internet was at a crawl. I traced the problem back to a large number of inbound connections that completely overwhelmed my little router. (4096 connections, the configured limit) All the connections were being made to my tor relay from outside IPs. The tor log file was filling with this: Oct 13 14:21:29.000 [warn] assign_to_cpuworker failed. Ignoring. Oct 13 14:21:29.000 [warn] assign_to_cpuworker failed. Ignoring. Oct 13 14:21:30.000 [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. [1779 similar message(s) suppressed in last 60 seconds] I shutdown the relay, then eventually disconnected my internal network from the router hoping the traffic would slow. It continued for maybe another 2-3 hours until I finally unplugged the router and left for the weekend. I was able to capture some of the traffic and found most of it originated from other tor (non-exit) relay nodes. In a 5 minute sample there was some 170,000 syn packets sent by some 4000+ unique IPs. I used a script to check the collected IPs against the list of known tor nodes and they're almost all tor (non-exit) relays. Hopefully it auto-fixes itself when I'm back at work Monday morning. But mostly I'm curious to know what's going on. Anybody encounter a situation like this?

2 1

hi-jacking an onion address
by Toralf Förster 14 Oct '17

14 Oct '17

2 4

spurios warning about using the nickname instead of the key
by Toralf Förster 12 Oct '17

12 Oct '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm wondering why I suddenly got at both of my 2 Tor exit relays (0.3.2.2.-alpha, running at the same machine) the following message: /tmp/notice2.log:Oct 07 22:41:58.000 [warn] You specified a relay "zwiebeltoralf2" by name, but nicknames can be used by any relay, not just the one you meant. To make sure you get the same relay in the future, refer to it by key, as "$6EABEBF38CE7E3DF672C4DB01383606FE3EB2215". /tmp/notice.log:Oct 07 22:39:53.000 [warn] You specified a relay "zwiebeltoralf" by name, but nicknames can be used by any relay, not just the one you meant. To make sure you get the same relay in the future, refer to it by key, as "$1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA". when I queried the Tor status via a home-brewed Python script [1]. I do assume that the message is related to line 90 ot that script: flags = controller.get_network_status(relay=srv.nickname).flags Because I'm using the script few times per day I do wonder why this happens today for the first time at all (IIRC) and just only once. [1] https://github.com/toralf/torutils/blob/master/info.py - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWdk/PxccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTpf8APwO30SS3Sbn1OhzOpFoJocdhj4k 7h/h6s5c0asDdwWkfwD/aaZpaP/ds9l4N9rivQSGW40Rv1Deqhuj/5fPtVizHeE= =8w5x -----END PGP SIGNATURE-----

8 11

Revert back to a stable build of Tor from an alpha
by Jacki M 12 Oct '17

12 Oct '17

How do I revert back to a stable build of Tor from an alpha? Im running Tor 0.3.2.2-alpha and need to revert back to Tor 0.3.1.7. Im running Ubuntu 16.04.3 LTS.

3 3

(no subject)
by Laty Luck 11 Oct '17

11 Oct '17

help

2 1

dnsmasq configuration for an exit relay (Debian)
by jpmvtd261＠laposte.net 10 Oct '17

10 Oct '17

Hello, I am looking for instructions on how to configure dnsmasq on a Debian exit relay (in order to cache DNS queries). It looks like this package could introduce vulnerabilities if not handled properly, because it provides more than just local DNS cache. If I had to install it without any advice, I would do this : 1) Install dnsmaq package with the command "aptitude install dnsmask" . 2) Make sure that the first line of the file /etc/resolv.conf is "nameserver 127.0.0.1" (see https://wiki.debian.org/HowTo/dnsmasq#Local_Caching ). 3) Make sure that the file /etc/dnsmasq.conf contains the line "listen-address=127.0.0.1" (to restrict dnsmasq to the local system). 4) Set the cache size to 10000 by adding or editing this line "cache-size=10000" in the file /etc/dnsmasq.conf (as suggested by Igor Mitrofanov here https://lists.torproject.org/pipermail/tor-relays/2017-August/012708.html ). 5) Reboot (is it necessary ?). Does anyone think that this procedure could start a daemon listening on a port of my server ? Or is it safe to do this on my exit relay ? Regards

6 30

Looking for a 34C3 Voucher
by Paul 10 Oct '17

10 Oct '17

Anybody holding a Voucher for 34C3 in Leipzig at the end of December? https://tickets.events.ccc.de/34c3/docs/? While still running several Exits I would be more than happy to meet others there Thanks, Paul

3 3

Re: [tor-relays] Tor exit nodes attacking SSH?
by me＠eugenemolotov.ru 08 Oct '17

08 Oct '17

On 08/08/2017 01:48 PM, Steven Chamberlain wrote: > Further investigation shows that this happens for any destination IP > address, even where there's no SSH service running: Make a "trap" ssh server (for example on virtualbox machine without any sensitive data) and log in into it through tsocks. After that check from which ip it was logged in. This probably would be ip of the exit node.

5 4

Re: [tor-relays] Feedback wanted: letter to my university's library
by Alison Macrina 08 Oct '17

08 Oct '17

Hi AJ, Thank you for supporting Tor! I think it's a great idea to try to work with your university library to run a relay. I run the Library Freedom Project which helps libraries understand and use privacy tools (libraryfreedomproject.org) I can give you some advice based on my experience. William Denton: > On 1 October 2017, AJ Jordan wrote: > >> However I've just started college at the University of Rochester, >> which obviously presents a great opportunity to set up a relay on a >> really great network. I'm planning to reach out to the library with >> the following email and would love some feedback: > > Scott Bennett had excellent advice, +1 > Academic libraries can be very experimental in some of their work, but > they are generally risk-averse. (This is good, because they're in the > business of preserving knowledge and cultural artifacts for decades and > centuries.) There is, I'm afraid, close to zero chance they would let a > non-employee student run a server on their network---and running Tor, > even a non-exit relay, makes the chances even lower. > > However, don't give up. I suggest thinking about this as a long-term > project that could get you involved with the library, faculty and campus > IT. There must be people on campus interested in privacy issues, who > know about Tor, and perhaps who have been thinking about running a > relay. These people could be librarians or they could be professors or > grad students in political science, communcations, journalism, computer > science, privacy studies, etc. Find out who they are and approach > them! Perhaps there is a student club interested in the same > issues---if not, you could start one. Students and student groups > advocating for a Tor relay or exit, while demonstrating the importance > of Tor and how it fits in with the library's and university's mission, > would very much help the project be successful. William's advice is good. You definitely need to begin by building a relationship with the library. Don't be discouraged by the amount of work this may take; the payoff might end up being a cultural shift wherein the library, university IT, and CS departments all work on this as a project together! You'll want to approach the library by showing that Tor is an excellent way to uphold the values of librarianship, which are privacy, intellectual freedom, and access. Really, be explicit about it; don't assume that they'll just get why you think it matters. Here's something I wrote about intellectual freedom + Tor Browser a while ago and you can borrow the arguments I've made: https://www.scribd.com/document/272919852/Alison-Macrina-The-Tor-Browser-an… As William said, libraries are mostly risk-averse, so you also need to be ready to answer their questions about legal and technical concerns. LFP has collected some resources to help with all of that here: https://github.com/LibraryFreedom/tor-exit-package/blob/master/resources.md. Before you email the university librarian, I'd start by talking to some of the regular academic librarians about your ideas and gauge their responses. Ask them if they've heard of the Library Freedom Project and feel free to send them any of our resources. See if they think the administration would be receptive to you offering a presentation about Tor to library staff (even better if you can make it open to students and faculty, too, because that can get you more support). You are welcome to adapt these slides for that presentation: https://libraryfreedomproject.org/allabouttor/. Make sure to show them this academic library that has used their Tor relay as a teaching tool for students: https://boingboing.net/2016/03/16/first-ever-tor-node-in-a-canad.html. LFP is fairly well known and respected in libraries and so if it can be beneficial to involve me further, I'm happy to assist! Alison

6 11