- tor-relays - lists.torproject.org

Is AboveClouds still active?
by Ralph Seichter 19 Oct '17

19 Oct '17

Does anybody here know if AboveClouds https://aboveclouds.co.uk is still in business? Emails sent to their support address have been unanswered for a month now. -Ralph

1 0

"Bug: Duplicate call to circuit_mark_for_close"
by tor 18 Oct '17

18 Oct '17

Hi, I'm troubleshooting a Linux relay where the Tor service is having problems. External monitoring alerts indicate both the ORPort and DirPort are unreachable (TCP connection timeout). I can ssh in and the Tor service is still running. The node seems to have increased memory usage at this point but there's no evidence of OOM. I restart the Tor service, monitoring says all is good again, and things seem fine for a bit, until the cycle repeats hours later. I'm still investigating, but one thing I immediately noticed was hundreds of these lines in the logs: [warn] circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/or/onion.c:238 (first at ../src/or/command.c:579) (on Tor 0.2.9.11 ) I found https://trac.torproject.org/projects/tor/ticket/20059 but it's marked as fixed with a backport to 0.2.9. Any thoughts?

4 9

vsif.ca relays: MyFamily configuration
by nusenu 18 Oct '17

18 Oct '17

Hello Vancouver Society for Internet Freedom, thanks for running tor relays. Unfortunately you are in a position that can potentially harm tor users if you do not set MyFamily (torrc) on all your relays. Please have a look at your MyFamily configuration. https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#vsif-suppor… You are also running an outdated version of tor that is no longer recommended: https://atlas.torproject.org/#search/vsif%20version:0.2.9.10 some more background: https://hackernoon.com/some-tor-relays-you-might-want-to-avoid-5901597ad821 Let us know if you need help with configuring MyFamily. thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Used TLS implementations by relays
by nusenu 15 Oct '17

15 Oct '17

Hi, are there any TLS libraries other than - openssl - libressl that are actively used by current tor relays? https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Overview thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Hashed password behaviour
by Geoff Down 15 Oct '17

15 Oct '17

Hello all, what sort of crazy bug would make Tor give different hashes for the same password? $ tor --hash-password hello 16:735E6FA5355D4146606AFE25B61B411DF419878C99705164D038FC99BC $ tor --hash-password hello 16:8201E7D35BB8CACB60BF8947B49A3480BA1A17E77EDA8BE45790746884 $ tor --version Tor version 0.3.1.7 (git-6babd3d9ba9318b3). (on OSX 10.4). GD

3 5

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

About relay size
by IPonU 07 Oct '17

07 Oct '17

Hi Tor list, I'm already running a small exit node (100Mbps bandwidth) and I'm ready to spend more money on it, so have a question for you guys : Is it better if I run other small ones (100Mbps too) or only 1 big exit relay (1 Gbps) ? What's best for the network stability/security ? Thanks a lot IPonU

13 34

anonymaid tor relays: MyFamily configuration
by nusenu 07 Oct '17

07 Oct '17

Hello anonymaid Relay Operator, thanks for running relays. Since you recently added more relays you are now in a position that can potentially harm tor users if you do not set MyFamily (torrc) on all your relays. Please have a look at you MyFamily configuration. https://nusenu.github.io/OrNetStats/endtoend-correlation-groups some more background: https://hackernoon.com/some-tor-relays-you-might-want-to-avoid-5901597ad821 Let us know if you need help with configuring MyFamily. thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

More recent rpm somewhere?
by Patrick DERWAEL 07 Oct '17

07 Oct '17

Hi folks, I'm running a few relays on CentOS 7 As I'm sticking to the ease of rpm distributions, I'm left behind on 0.2.9.10 from EPEL Does anyone know of another rpm repository with a more up to date version ? Thanks! Patrick

5 7

Blocking outbound 22 or no?
by AMuse 06 Oct '17

06 Oct '17

Hi all! I'm getting a number of ISP Abuse complaints around outbound ssh brute-forcing from our exit relay. I'm personally of the opinion that people should run fail2ban (or equiv) and get on with life and I generally ignore the complaints - but wondered, what are other operators doing? Is anyone exit-policy blocking outbound 22 to make the internet a kinder place? Is anyone refusing to on principle?

5 4

Quintex Exit Relays
by John Ricketts 05 Oct '17

05 Oct '17

All, I am performing some operating system upgrades and my exit nodes may be down for a period of time. Just a heads up. John

1 0

Re: [tor-relays] AU Relays and data retention
by Paul Templeton 05 Oct '17

05 Oct '17

Thanx Teor, I did speak to a lawyer and there is no requirement to retain any data if you run a node. It's treated as a VPN. My question that I sent was more about whether a service (non commercial service) was exempt. They don't delineate. Paul

2 1

AU Relays and data retention
by Paul Templeton 05 Oct '17

05 Oct '17

Hi All, I have asked the Attorney Generals Department about data retention and got the following response. If you run a relay/bridge here you seem to be exempt from retaining data. If your not an ISP and you run a service from home the ISP/carrier will retain the data though. This just general information. Regards, Paul UNCLASSIFIED Dear Mr Templeton Thank you for your enquiry to the Office of Communications and Cybercrime. I am re-sending our reply to your original enquiry that we sent on 12 September 2017 that seems to have not arrived. The extent of data retention obligations for your relevant service would relate to the extent to which elements of the data set “visible” to you. For example, where a provider does not have “visibility” of a customer’s IP address, it is likely that the IP address was assigned as part of a different relevant service. For example, if you have a record of the MAC addresses of users who access your network then this information must be retained for the required period. You are not obliged to retain the identity of the user if this is not information to which you have access. Whether the service is being offered on a commercial basis or is free is irrelevant in determining a service provider's obligations. In your email you noted that "The true origin of a connection and the true destination will never be known and there will be no way of obtaining the information. That also pertains to the ports used in the circuit and all data passing through the circuit will be encrypted." This sentence appears to suggest that you may be looking to offer some kind of an internet access service, in which case the destination is not required to be retained. Your reference to encrypted content suggests a VPN. If this is the case and this service is not operated you, obligations do not apply. Also, data retention would not require you to store the contents of the communications. Please do not hesitate to contact our office if you require further information. Regards Kerry Office of Communications Access & Cybercrime Intelligence and Identity Security Division T: (02) 6141 2884 The information contained in this email is intended as guidance only. It does not constitute legal advice and should not be relied upon as such. If you require legal advice, you should consult an independent legal adviser.

3 3

SSH Bruteforce Attempts
by tanous .c 04 Oct '17

04 Oct '17

Hi, I have been running one tor exit relay for about 51 days and i recently got this abuse report: Good afternoon, Your Ip address (212.47.239.73) has been reported to us by profihost because it seems to have attempted to bruteforce. Thank you to take the necessary action as soon as possible. You will find more information about this report below this message. Feel free to contact Online.net technical assistance for more information. Online.net Abuse service ------------------------------------------------------------------------------ (time is MET / GMT+1): Tue Oct 3 08:59:40 2017: user: root service: ssh target: 77.75.252.250 source: 212.47.239.73 Tue Oct 3 08:59:10 2017: user: root service: ssh target: 77.75.252.250 source: 212.47.239.73 Tue Oct 3 08:59:10 2017: user: root service: ssh target: 77.75.252.250 source: 212.47.239.73 Tue Oct 3 08:36:18 2017: user: admin service: ssh target: 37.228.155.188 source: 212.47.239.73 Tue Oct 3 07:06:42 2017: user: user service: ssh target: 77.75.252.80 source: 212.47.239.73 Tue Oct 3 07:06:12 2017: user: user1 service: ssh target: 77.75.252.80 source: 212.47.239.73 Tue Oct 3 06:14:12 2017: user: admin service: ssh target: 77.75.251.85 source: 212.47.239.73 Tue Oct 3 06:01:41 2017: user: admin service: ssh target: 77.75.252.78 source: 212.47.239.73 Tue Oct 3 05:37:01 2017: user: admin service: ssh target: 185.39.221.52 source: 212.47.239.73 Tue Oct 3 02:07:46 2017: user: admin service: ssh target: 77.75.249.19 source: 212.47.239.73 Tue Oct 3 01:23:57 2017: user: admin service: ssh target: 85.158.176.137 source: 212.47.239.73 Mon Oct 2 20:10:45 2017: user: admin service: ssh target: 77.75.255.76 source: 212.47.239.73 Mon Oct 2 17:30:13 2017: user: admin service: ssh target: 185.39.221.145 source: 212.47.239.73 Mon Oct 2 17:30:13 2017: user: admin service: ssh target: 185.39.221.145 source: 212.47.239.73 Mon Oct 2 17:09:32 2017: user: admin service: ssh target: 37.228.154.149 source: 212.47.239.73 Mon Oct 2 17:09:23 2017: user: admin service: ssh target: 37.228.154.102 source: 212.47.239.73 Mon Oct 2 16:43:12 2017: user: admin service: ssh target: 77.75.252.233 source: 212.47.239.73 Mon Oct 2 16:23:41 2017: user: admin service: ssh target: 37.228.155.125 source: 212.47.239.73 Mon Oct 2 14:17:24 2017: user: admin service: ssh target: 77.75.250.84 source: 212.47.239.73 Mon Oct 2 13:24:14 2017: user: supervisor service: ssh target: 37.228.159.139 source: 212.47.239.73 Mon Oct 2 13:24:14 2017: user: support service: ssh target: 37.228.159.139 source: 212.47.239.73 Mon Oct 2 13:23:44 2017: user: super service: ssh target: 37.228.159.139 source: 212.47.239.73 Mon Oct 2 12:48:09 2017: user: user service: ssh target: 37.228.159.98 source: 212.47.239.73 Mon Oct 2 12:47:39 2017: user: user service: ssh target: 37.228.159.98 source: 212.47.239.73 ------ This data has been truncated because it was too long ------ Have any of you had this sort of problem? I'm having difficulty determining if this log information represents a normal exit relay ocurrence or if my server has been compromised... What could i do in order to solve this? Thank you all, Tanous

4 4

SSH brute force attempts to connect to my Middle Relay IP address
by Fr33d0m4all 04 Oct '17

04 Oct '17

Hi, My Tor middle relay public IP address is victim of SSH brute force connections’ attempts and the attack is going on since two weeks ago. It’s not a problem, the server that is listening with SSH on the same IP address than my Tor relay blocks the connections and bans the IP addresses (with Fail2Ban) but I just wanted to know if there is some campaign of attacks carried against Tor relays.. are you experiencing the same? The attacks are carried on with a botnet given the large amount of different IP addresses that I see in the logs. Best regards, Fr33d0m4All

10 11

Attacks to and from Tor
by Thomas Dünser 04 Oct '17

04 Oct '17

Hi everybody, I've read a few threads about attacks from exit nodes to the clear net and from the clear net to tor nodes and have several questions: -How can you recognize that the attacks to tor nodes are especially against Tor? -And how can a clear net user or better IDS easily differencing between an attacker that comes over Tor (exit node) or from a clear net host? I think this is important to categorize the situation. Thanks, Tom

2 1

Feedback wanted: letter to my university's library
by AJ Jordan 02 Oct '17

02 Oct '17

Hey, all! I'm AJ; I've been lurking on this list for many years but have never had cause to post. I've run a Tor relay (`strugees`) on AWS for a number of years now, but haven't been able to dedicate all that much bandwidth to it due to cost concerns. 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: > Heya! > > I'm a new first-year student and I'm active in the technology > activism community. One of the things I'm very interested in is the > Tor Project (https://torproject.org) whose mission is to make it > possible to freely and anonymously use the internet, without fear of > surveillance or censorship. Tor is used by a wide variety of people > - activists, journalists, corporations, law enforcement, and > individuals - to gain free access to information and speak their > mind. Tor is able to provide this free expression by utilizing a > worldwide network of relays run by volunteers. A relay can make a > big difference on the Tor network if it's run on a connection which > is fast and has lots of bandwidth - like the University's > connection. > > I think it would be really cool if UR would donate part of its > internet resources to the Tor network. I considered directly > contacting IT, but I thought it actually made sense to talk to the > library first since the core values are actually really similar - > libraries and the Tor project both know the value and power of > unrestricted access to information and are dedicated to making > information available to anyone who wants it. > > If this is something that sounds interesting, I would love to chat > about this in person. I would also be willing to invest the time > needed to administrate the relay - I have several years of > experience doing this already, but haven't had access to the > resources the University has. > > Thanks very much! > > AJ Jordan Does anyone who's done something like this before have any tips or suggestions? Am I going about this in the best way? Cheers! AJ

8 9

Relay uptime versus outdated Tor version
by K. Besig 02 Oct '17

02 Oct '17

One of my relays has over 416 days of uptime, which I'm very proud of, however it's running an outdated version of Tor. I should probably already know the answer, but it seems to me I would have to stop the tor service to update the relay. Would I in fact lose my uptime or would it be seamless? Thanks for the response

14 21

bwauths doesn't reach reliable my relay
by Toralf Förster 30 Sep '17

30 Sep '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I do wonder why both longclaw and Faravahar seems since few days not to reach my relays 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA and 6EABEBF38CE7E3DF672C4DB01383606FE3EB2215 respectively - resulting in a bw value of 20. B/c I switched to version 0.3.1.7 I do wonder if this could be the culprit ? - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWcwE1BccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTik4AP4ubRPDKm3jz73xGXmNAhupWarC 9pVPhRNqoD19jgpbGwD/QUnYKHIpbV4983kVMBjr9vbt2zwHRwmT0o+YMFJEVws= =NYwf -----END PGP SIGNATURE-----

3 6

Re: [tor-relays] About relay size
by Dhalgren Tor 30 Sep '17

30 Sep '17

FWIW I run a 100TB (150mbps) exit and am convinced that this size provides better quality exit connectivity than the highest ranked monster bandwidth relays. The biggest relays attract the greatest blacklist treatment due to the volume of abuse emanating from them. As a user of Tor I frequently observe connection attempts commencing with a handful of top-rated relays, only to work down to a mid-bandwidth relay such as mine before successfully completing. For this reason I would like to see the exit selection algorithm bias somewhat away from relays rated over 50000. Is annoying to wait 30 seconds for the discovery of a usable path. Hard 100mbps connections will be easier to manage than the 100TB class of service, as the latter is usually over a 1GB link with a FUP (fair use policy) associated with it and extravagant surcharges for exceeding the limit. ________________________________ >Hi Tor list, > >I'm already running a small exit node (100Mbps bandwidth) and I'm ready >to spend more money on it, so have a question for you guys : > >Is it better if I run other small ones (100Mbps too) or only 1 big exit >relay (1 Gbps) ? What's best for the network stability/security ? > >Thanks a lot > >IPonU

1 0

Info about HW Encryption on Raspberry
by Fr33d0m4all 29 Sep '17

29 Sep '17

Hi, I have a Raspberry Pi3 that runs a Tor mid-relay and I’ve noticed that in the last weeks it reaches high temperatures (about 76°C) due to high CPU usage when Tor traffic increases. It did not reach this temperature until this summer (but it is not due to an higher environment temperature), so I don’t know if it can be related to 0.3 version. Now I’m running Tor 0.3.1.7. Should Tor 0.3.x use Raspberry Pi3 AES-NI hardware acceleration to reduce high cpu usage? Is there a way to check and enable it if disabled? # openssl speed -evp aes-256-cbc Doing aes-256-cbc for 3s on 16 size blocks: 5560204 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 1631984 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 425826 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 107776 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 13489 aes-256-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Jan 27 22:44:27 2017 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256-cbc 29654.42k 34815.66k 36337.15k 36787.54k 36833.96k Best regards, Fr33d0m4All

2 1

NTor
by Sebastian Urbach 29 Sep '17

29 Sep '17

Dear List, I just noticed an increase from 670k to 8.8 million NTor handshakes. CPU load reached the limit and Consensus Weight dropped. Something is going around ... https://atlas.torproject.org/#details/4198BD138E5E11B15B05C826B427148CED7D9… -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach --------------------------------------------------------------------------- Those who surrender freedom for security will not have, nor do they deserve, either one. --------------------------------------------------------------------------- Benjamin Franklin (1706-1790)

1 0

No Gaurd
by Kurt Besig 28 Sep '17

28 Sep '17

https://atlas.torproject.org/#details/E65D300F11E1DB12C534B0146BDAB6972F1A8… Relay looks pretty stable to me, I'm re-visiting the lack of guard status... ideas?

4 3

MaxMemInQueues defends against 375000 circuits in 9 secs
by Felix 28 Sep '17

28 Sep '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everybody Another circuit storm, right ? - ---- MaxMemInQueues 2 GB - ---- 2017-09-26_17-55-00: PID JID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 84847 2 256 6 20 0 484M 427M uwait 0 907:02 11.77% tor 2017-09-26_18-59-00: PID JID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 84847 2 256 6 20 0 2437M 2380M uwait 0 917:03 18.26% tor - ---- On Tor 0.3.2.1-alpha 290274dbb5428bc5 Sep 26 18:24:37.000 [notice] Heartbeat: Tor's uptime is 4 days 18:59 hours, with 13714 circuits open. I've sent 2459.48 GB and received 2422.58 GB. Sep 26 18:24:37.000 [notice] Circuit handshake stats since last time: 4635/4635 TAP, 113271/113271 NTor. Sep 26 18:24:37.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 3 v3 connections, and 214559 v4 connections; and received 886 v1 connections, 24624 v2 connections, 60722 v3 connections, and 354411 v4 connections. Sep 26 18:59:28.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Sep 26 18:59:28.000 [notice] Removed 106528 bytes by killing 14408 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Sep 26 18:59:28.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Sep 26 18:59:28.000 [notice] Removed 528 bytes by killing 7 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. ... ************************************************************************ **************** 2500 x removed some bytes by killing between single and 300 circuits (constantly increasing sawtoothy, average 150 circuits) average 150 circuits x 2500 = 375000 circuits avoided in 9 seconds ************************************************************************ **************** ... Sep 26 18:59:37.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Sep 26 18:59:37.000 [notice] Removed 4624 bytes by killing 115 circuits; 0 circuits remain alive. Also killed 1 non-linked directory connections. [] https:// lists.torproject.org/pipermail/tor-relays/2017-July/012624.html - -- Cheers, Felix -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZyqCOAAoJEF1W24InZUQd/eAQAIK7IDNbnR+E1uTpvVwimUCJ jrSPr5sCXu8t4ly0Tci/tg7mCGTd9xKJvJgUHLei7pd6UmdDJvwajrX08tE/iBC/ uJPLEr69OBBqDICf7E+Y4oQGRz4ICY/4IGeb7lU/My6TzT00gHcs0/0tuww1actm P06uobAeRx+56GCg9hGopLavSOIHsR0bFC3k5kqin79qx40XwNuN6xkFCDni/fHW EO9GazD2iE4zJ3+1lIJsIzaA7fgu+Ack2GcLpaPKMNMwX3DagG/A619HsddOoBfH EFV2ZOhnR9XWytgIfPX4e/gErTHvWPshm0qaO4PzxwAlAoSKygvz497O1HZ3AlM+ fcn+C/fkfCcU2PYVPXKV3vDzupiZ17OJGfRNtAy1EqFLCK6q7xQAp1e3JuRJZBDO 3E/18FJM7JXCUz5StxwB+oAu9LGib50vXbtAOtuLwfX4OC3Nl0Fc/gw0ueYwWIPu QvsU0WNelwaUo3wWs47fJsMsJqjpt0Uywh8yvK809xvqogUFiQBF2ynIp5QzfaJ0 or/7axRHXglkxVaF+q84GFG8LAaspurGauQQFtzUdzl/ljWC963PyrGiOr0kCj/R OIc3TDSDYopFTllXeeVu2bysW7PrzL3vu5rcOHbbVAnUoRukA4Hh6qJFQuTk+Ndb tT8G8jk1QJjRqH/IaTLg =r7/i -----END PGP SIGNATURE-----

3 3

IPonU tor relays: MyFamily configuration
by nusenu 27 Sep '17

27 Sep '17

Hello IPonU Relay Operator, thanks for running relays. Since you recently became a tor exit operator you are now in a position that can potentially harm tor users if you do not set your MyFamily on all your relays. Please have a look at you MyFamily configuration. https://nusenu.github.io/OrNetStats/endtoend-correlation-groups some more background: https://hackernoon.com/some-tor-relays-you-might-want-to-avoid-5901597ad821 Let us know if you need help with configuring MyFamily. thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Individual Operator Exit Probability Threshold
by John Ricketts 27 Sep '17

27 Sep '17

All, I have brought this question up in meetings in Seattle and other places so some of you may have already heard me ask this question. So, at risk of repeating the question for some... here goes. I am about to fire up more Exit Relays and if I do so I will jump from my roughly 3% of Exit Probability to what technically could easily reach 6-8%. I would like to know everyone’s opinion on having an individual operator have that much exit share. In my case, all the traffic would be coming from the same AS as well, but distributed over four different cities with different upstream carriers. Please chime in, if I get the a green light from the discussion it will happen within a month. Sincerely, John L. Ricketts, PhD Quintex Alliance Consulting

13 20

On some differences after upgrade to latest tor for Jessie
by a tor op 26 Sep '17

26 Sep '17

Hi I'm running an obfs4 bridge and upgraded to latest version. Use Debian Jessie (8.9). One thing that puzzles me is the log /var/log/tor/log I used to always see some useful info there, like number of connecting clients during the last 6 hours etc. I have an entry: [notice] Clean shutdown finished. Exiting. at the end of the file with time stamp from when the upgrade was performed but today's version of it is NUL. I also noticed that for some reason the 'service tor restart' etc command does not work. Or am I mixing this with Ubuntu now?!.. And it does not give any info back on terminal. Weird. Maybe it has something to do with that shit systemd I donno. I have a limited time troubleshooting this right now since I also do other things in life than troubleshoot tor. 'systemctl status tor' gives info like this: systemd[1]: Reloaded Anonymizing overlay network for TCP and seem to indicate that everything is running with some other stats info. It also seems to work and Atlas has it Green and there seems to be connections coming in and so on. Can someone fill me in on wtf is going on? I'd like to know about the differences I feel I am experiencing, the lack of feedback from 'service' command and the empty tor log file. TIA

3 2

>18k 'Machiavelli' bridges added since 2017-09-02 (>4k currently running = 64% of bridges)
by nusenu 25 Sep '17

25 Sep '17

Hi, do you know anything about >18k Machiavelli named bridges that have been added in the last few days? (>4k currently running) thanks, nusenu properties: OS: Linux tor version: 0.3.0.10 transports: obfs4 https://twitter.com/nusenu_/status/905580044503969792 new bridges per first_seen date: [...] | 2017-09-02 13:43:33 | 1 | < usual rate | 2017-09-02 14:43:33 | 2 | | 2017-09-02 15:43:33 | 1 | | 2017-09-02 17:43:33 | 1 | | 2017-09-02 18:43:33 | 1360 | < Machiavelli bridges start here | 2017-09-02 19:43:33 | 667 | | 2017-09-02 20:43:33 | 196 | | 2017-09-02 21:43:33 | 184 | | 2017-09-02 22:43:33 | 196 | | 2017-09-02 23:43:33 | 189 | | 2017-09-03 00:43:33 | 196 | [...] | 2017-09-06 18:43:33 | 152 | | 2017-09-06 19:43:33 | 149 | | 2017-09-06 20:43:33 | 148 | +---------------------+----------+ First Machiavelli named bridge (running in the last 7 days) appeared on 2016-11-28 00:41:02 -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 3

Accounting logic
by r1610091651 25 Sep '17

25 Sep '17

Hi I'm on version 0.3.1.7 on Linux. I've following config entries: AccountingMax 1639 GBytes AccountingStart month 24 00:00 Today I've discovered following log entries: Sep 24 00:00:00.000 [notice] Configured hibernation. This interval began at 2017-09-24 00:00:00; the scheduled wake-up time is 2017 -09-28 16:44:28; we expect to exhaust our quota for this interval around 2017-10-21 20:52:28; the next interval begins at 2017-10-24 00:00:00 (all times local) Sep 24 00:00:01.000 [notice] Commencing hibernation. We will wake up at 2017-09-28 16:44:28 local time. Sep 24 00:00:01.000 [notice] Going dormant. Blowing away remaining connections. For context, Tor did not exceed previous quota and was operating normally before 24 september 00:00. To me this is not what I would have expected as behaviour given the config. My exception is that the tor would reset counters at month end/beginning and continue operation. Is it a bug? Thanks Sebastian

2 2

update installation guide please
by I 24 Sep '17

24 Sep '17

2 1

bad exit flag reason
by nusenu 24 Sep '17

24 Sep '17

Hi, [1] is not maintained since a long time. I'm curious what the reason for assigning the badexit flag to [2] was. If you know anything about it and can share something, that would be great. thanks, nusenu [2] https://atlas.torproject.org/#search/flag:badexit 37.221.171.234 75FCEA0BE7A2A472669352A1F0F2E59F99C6A3AA 37.221.171.237 128814837EC27F20D76EBDDB2CB3AB70258F0BA8 [1] https://trac.torproject.org/projects/tor/wiki/doc/badRelays -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 3

bug messages in my relay's notices.log
by Scott Bennett 23 Sep '17

23 Sep '17

I've gotten a couple of these sets of messages in the last few hours. Sep 22 05:13:17.366 [warn] tor_bug_occurred_: Bug: src/common/compress.c:576: tor_compress_process: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed. (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed in tor_compress_process at src/common/compress.c:576. Stack trace: (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x11a63fc <tor_bug_occurred_+268> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x11abbd4 <tor_compress_process+228> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x11ab0fa <tor_compress+554> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x11ab540 <tor_uncompress+64> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x114ecfd <connection_dir_reached_eof+1773> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x1126c43 <connection_handle_read+3027> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x106db94 <connection_add_impl+532> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x1c1e8564e <event_base_assert_ok_nolock_+3102> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x1c1e80a1e <event_base_loop+1310> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x106fa55 <do_main_loop+1413> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x1071e89 <tor_main+233> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x106d899 <main+25> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) Sep 22 05:13:17.366 [warn] Bug: 0x106d791 <_start+417> at /usr/local/bin/tor (on Tor 0.3.1.6-rc efc306c59aa9ee1a) My outdated system is running FreeBSD 10.3-STABLE. I've never seen these messages before that I can remember. What causes them? What, if anything, should I do about them? And what fallout do they cause for users? Thanks in advance for any relevant information! Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

3 5

tor on tails
by TorGate 23 Sep '17

23 Sep '17

Hi, can i setup a tor server with tails ? I planing 4 new tor servers TorGate1,2,3,4 . Is this a god ide ? Steffen

2 1

abuse email for non-exit relay (masergy)
by relay 000 23 Sep '17

23 Sep '17

FYI, I got this email for a non-exit relay - please share if you get them as well: To Whom it May Concern, You have a system on your network that is actively scanning and/or attacking external sites on the Internet. This can come from many sources and because it is often difficult to detect this activity, we are sending this E-mail in an attempt to help you solve the problem. We have detected your system with an IP of, <relay-IP>, scanning a client we monitor. This was not a short attack but a prolonged scan and/or probe that was designed to find and intrude into the target network. This may be someone on your network who is actively trying to hack others. This person may be a legitimate user on your network or it may be that this system has been compromised and is being used by someone to hack others. It is also likely that the system is running automated tools that have been installed to perform these actions without any human intervention. Below is the information about the attack. Keep in mind that the source IP of our client has been sanitized for anonymity. Date: 09/XX/2017 Time Zone: America/Chicago Source(s): relay-IP Type of Attack/Scan: Generic Hosts: <RFC1918 IP address> Log: relay-IP:ORPort > RFC1918 IP address Possible Cause: Thank you for your attention to this matter, Masergy email: esp(a)masergy.com mailto:esp@masergy.com ---------------

6 10

Bug Report for 3.1.7 (Debian)
by Sebastian Urbach 22 Sep '17

22 Sep '17

Good Morning, I just updated my Exit to 3.1.7 (Debian) a few hours ago and found this: [warn] tor_bug_occurred_(): Bug: ../src/common/compress.c 576: Sep 22 15:01:46.000 [warn] Bug: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *iSep 22 15:01:46.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x43) [0x560c022013eSep 22 15:01:46.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x560c022Sep 22 15:01:46.000 [warn] Bug: /usr/bin/tor(tor_compress_process+0x135) [0x560Sep 22 15:01:46.000 [warn] Bug: /usr/bin/tor(+0x18e715) [0x560c02223715] (on To 1Help 2Wrap 3Quit 4Hex 5Goto 6 7Search 8Raw 9Format 10Quit Please contact me for further information if needed. -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach --------------------------------------------------------------------------- Those who surrender freedom for security will not have, nor do they deserve, either one. --------------------------------------------------------------------------- Benjamin Franklin (1706-1790)

3 2

FallbackDirectoryMirrors selection criteria "uptime"
by Martin Kepplinger 22 Sep '17

22 Sep '17

hi, Fallback directory mirrors [1] seem to be selected (if the need should arise, according to release planning and whatnot) with criteria "uptime", among others. And it's only this criteria I'm thinking about here: Now, in the wiki we have advice on how to improve relay security, and among many, there is advice to wipe the master key / identity every 1-2 years [2]. Fallback directory mirrors are *selected* based on uptime, and *expected* to stay up, of course, for about at least 2 years. This somehow encourages to keep your identity forever. That's a contradiction and it might end up in *not* selecting relays, whos operators care a lot about security. thanks martin [1] https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors [2] https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity#Vector1:…

2 2

Horizons Relay Figerprint
by Kurt Besig 21 Sep '17

21 Sep '17

E65D300F11E1DB12C534B0146BDAB6972F1A8A48

3 2

Re: [tor-relays] tor-relays Digest, Vol 80, Issue 26
by flipchan 20 Sep '17

20 Sep '17

https://okservers.net/ doesn't provide vps :/ something like a good ISP that tolerate exit nodes would be good like something in holland maybe? On September 18, 2017 1:50:45 AM GMT+02:00, tor-relays-request(a)lists.torproject.org wrote: >Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > >You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of tor-relays digest..." > > >Today's Topics: > > 1. Re: Tolerant hosting for exit node. (King Queen) > 2. Re: Tolerant hosting for exit node. (Alec Larsen) > 3. Re: Tolerant hosting for exit node. (nusenu) > 4. Re: Tolerant hosting for exit node. (nusenu) > 5. Re: Tolerant hosting for exit node. (George) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sun, 17 Sep 2017 19:59:12 +0100 >From: King Queen <kingqueenits(a)gmail.com> >To: armenian_priest <tor-relays(a)lists.torproject.org> >Subject: Re: [tor-relays] Tolerant hosting for exit node. >Message-ID: <1674967117.20170917195912(a)gmail.com> >Content-Type: text/plain; charset=us-ascii > >https://box.cock.li FTW > >yeah it's servers with cocks, but it is in Romania / IP location the >Seychelles, and I have had no issues with my exit node on them. > > > >Sunday, September 17, 2017, 11:32:33 AM, you wrote: > >> Hello list, > >> I was hoping to get a good suggestion from here for a hosting >provider >> that is tolerant with Tor exit nodes. > >> I went through the mailing list archive a few months back and there >> weren't any good suggestions on hosting providers. > >> Also, I checked the 'GoodBadISPs' page in the Tor wiki but it is >pretty >> outdated and I already got burned with one provider from there: >ITLDC, >> it was added on 2016-04-23 but they bluntly stated that they DO NOT >> tolerate exit nodes after 2 abuse complaints, my exit node was >running >> for 1 month there. > >> One of the abuses was handled but with the second one they basically >> wanted me to block HTTP/S traffic on the VPS. > >> I am not sure who edits and keeps track of the mentioned page but it >> would be a good idea to remove the mentioned provider from there so >> other people wont waste their money. > >> Hope to get some recommendations since I want to support the network >> with an exit node. > >> Thanks in advance! > >> With regards, > >> jack > > >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > >-- >Best regards, > King mailto:kingqueenits@gmail.com > > > >------------------------------ > >Message: 2 >Date: Sun, 17 Sep 2017 22:41:53 +0000 >From: Alec Larsen <aleclarsen42(a)gmail.com> >To: armenian_priest <tor-relays(a)lists.torproject.org> >Subject: Re: [tor-relays] Tolerant hosting for exit node. >Message-ID: > <CANw7z-gfKu72VkdQFL0FfZqCeMqmkqW1C3AaAjLeDcm1tsxHng(a)mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >https://okservers.net/ is newer, but they are Tor friendly, very price >competitive, and allow payment in Bitcoin. > >On Sun, Sep 17, 2017 at 1:59 PM King Queen <kingqueenits(a)gmail.com> >wrote: > >> https://box.cock.li FTW >> >> yeah it's servers with cocks, but it is in Romania / IP location the >> Seychelles, and I have had no issues with my exit node on them. >> >> >> >> Sunday, September 17, 2017, 11:32:33 AM, you wrote: >> >> > Hello list, >> >> > I was hoping to get a good suggestion from here for a hosting >provider >> > that is tolerant with Tor exit nodes. >> >> > I went through the mailing list archive a few months back and there >> > weren't any good suggestions on hosting providers. >> >> > Also, I checked the 'GoodBadISPs' page in the Tor wiki but it is >pretty >> > outdated and I already got burned with one provider from there: >ITLDC, >> > it was added on 2016-04-23 but they bluntly stated that they DO NOT >> > tolerate exit nodes after 2 abuse complaints, my exit node was >running >> > for 1 month there. >> >> > One of the abuses was handled but with the second one they >basically >> > wanted me to block HTTP/S traffic on the VPS. >> >> > I am not sure who edits and keeps track of the mentioned page but >it >> > would be a good idea to remove the mentioned provider from there so >> > other people wont waste their money. >> >> > Hope to get some recommendations since I want to support the >network >> > with an exit node. >> >> > Thanks in advance! >> >> > With regards, >> >> > jack >> >> >> > _______________________________________________ >> > tor-relays mailing list >> > tor-relays(a)lists.torproject.org >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> >> >> -- >> Best regards, >> King mailto:kingqueenits@gmail.com >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >

4 5

Some Dir Authorities blocked
by Graeme Neilson 20 Sep '17

20 Sep '17

Hi, I am running a relay but 4 out of 8 directory authorities appear to being blocked by my ISP. There is no route to the blocked authorities and the last responding tcp traceroute hop is an ISP machine. There are routes via IPv6 though. Is there anything I can do to get my relay in the consensus? Thanks, G

10 16

A Common Thread: Guard Status
by Kurt Besig 20 Sep '17

20 Sep '17

Just curious and I know it's probably been answered 100x times... I recently updated Tor to an, 'approved version', after 340+ days of up time. Upon restarting the relay, 25 days ago, Ive not been given the 'guard flag' again. Why? Thanks

4 4

Advisory: Stack disclosure in hidden services logs when SafeLogging disabled
by Nick Mathewson 18 Sep '17

18 Sep '17

[TROVE-2017-008. CVE-2017-0380. Severity: medium] Hello! We have found a possible problem with the code that reports an error during the construction of an introduction point circuit. Because of this bug, it is possible that some hidden services will sometimes write sensitive information into their logs. This bug can only happen when the SafeLogging option is disabled, and SafeLogging is enabled by default. If you have not disabled SafeLogging, then you should be fine. We are tracking this bug as TROVE-2017-008 and as ticket #23490. It is also CVE-2017-0380. MITIGATION: 1. If you are not running a hidden service, then you don't need to do anything. This bug does not affect you. 2. If you are running 0.2.5.x, this bug does not affect you: it first appeared in 0.2.7.2-alpha. Other bugs do affect you, though: 0.2.5.x is pretty old! (If you are running 0.2.4, or 0.2.6, or 0.2.7, you should just upgrade. We aren't supporting those releases.) 3. Make sure that you did not change the value of the SafeLogging option in your configuration -- or if you did, that you set it to "1". SafeLogging needs to be turned to "0" or "relay" for this bug to occur. 4. If you did disable SafeLogging, re-enable it: Set it to 1, and use a HUP signal to tell Tor to reload its configuration. 5. If you did disable SafeLogging, you should delete any old logs that were generated with SafeLogging disabled. (You should be regularly removing old logs anyway, as a best security practice.) ACKNOWLEDGMENTS: We found this when we re-added scan-build's dead assignment checker into the checkers that we run on Tor. Obviously, it's time to make sure that scan-build gets run more frequently. FIX: There are patches for this issue linked from ticket #23490 on our bugtracker. I will be putting out updated releases today. This bug will be fixed in 0.2.8.15, 0.2.9.12, 0.3.0.11, 0.3.1.7, and 0.3.2.1-alpha.

2 2