tor-relays January 2015

tor-relays@lists.torproject.org

90 participants
70 discussions

Reminder: exit nodes probably shouldn't be using Google's DNS servers
by Nick Mathewson 25 Feb '16

25 Feb '16

Hi, all! While looking into a bug report, I noticed that an exit node was using one of Google's well-known public DNS servers for its own DNS server. No disrespect to the operators of Google's fine public DNS service, but my sense is that using it for a Tor exit node might not be the greatest idea for users' privacy, having one DNS provider that gets to see so many requests. It's probably a better idea to have your own local cacheing DNS server. Would anybody like to share a guide about how to set one of those up safely and migrate correctly? best wishes, -- Nick

23 38

onionoo backend seems to be down.
by jason＠icetor.is 21 Apr '15

21 Apr '15

Hello All, Anyone else notice onionoo and the tools that rely on it (globe.torproject.org atlas.torproject.org) seem to be down? -Jason

5 4

Tor and Freenode
by Markus Hitter 20 Apr '15

20 Apr '15

Hello all, after yesterday watching "State of the Onion", a speech held at 31C3 recently, I spontanuously decided to also run a Tor relay. After some back and forth it appears to be running fine on my OpenWRT based router. The only ORPort is 9001, which is also the only hole punched into the firewall, I hope I did this right. Today I wanted to continue at Freenode IRC, like I did for years, not even using an anonymous connection. But they wouldn't let me in: [12:02] * You are banned from this server- Your tor exit node must not allow connections to freenode (tor exit node (chat.freenode.net:8000)). Email tor-kline(a)freenode.net when corrected. (2015/1/24 09.41) I understand that my router and my PC share the same IP address to the remaining internet and IRC operators try to identify users by their IP address (which isn't possible). Reading up on the matter I found two texts: http://www.freenode.org/policy.shtml "The freenode network welcomes Tor users" http://www.freenode.org/irc_servers.shtml#tor "If you do want to be a Tor exit node and still use freenode, you will have to configure your exit policy to block all of the IRC ports we use, in addition to ports 80 and 443 as these are used for webchat." To me this sounds like "We welcome it, but please block all of its usage". They recommend to add a "reject *:*" rule, but that means the relay is no longer a relay, right? And blocking port 80 and 443 means Tor to become useless. As I can't find much on the matter by googling: is this actually a misalignment of Freenodes' statement to freedom as bad as it looks? If yes, what could I do about it? I'm a fairly experienced hobbyist hacker and admin, so I wouldn't fear writing some code. Cheers, Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/

14 27

eventdns: Address mismatch on received DNS packet.
by Jeremy Olexa 21 Feb '15

21 Feb '15

Hi List, I'm seeing these messages in one of my relays. Pretty often, too. eventdns: Address mismatch on received DNS packet. Apparent source was <IP>:<port> I've searched this and found references[1] to a faulty resolver of some type and torservers.net ignores the message[2]. I use my ISPs resolvers which are physically close to the server. In an attempt to fix this, I've added a caching local resolver to my server and configured resolv.conf properly (problem persists). Then I switched to Google DNS with caching in front (problem persists). Can anyone clarify what the problem may be? Or is it no problem at all? [1]: https://lists.torproject.org/pipermail/tor-relays/2013-July/002209.html [2]: https://lists.torproject.org/pipermail/tor-relays/2011-December/001034.html Thanks! -Jeremy

6 5

Making your relay submit hidden service statistics
by George Kadianakis 04 Feb '15

04 Feb '15

Hello people, some days ago we sent a mail [1] asking for feedback on our patch that collects hidden service statistics from Tor relays. Specifically, we are trying to answer the questions: "Approximately how many hidden services are there?" and "Approximately how much traffic of the Tor network is going to hidden services?". For more information see my previous email and the relevant proposals. Our code [2] got merged in upstream Tor some days ago and now we are looking for more volunteers to enable it on their relays. We will collect these statistics during the next [days] weeks, and in a month we plan to publish a short report with our findings. To help us you will need to use the very latest version of Tor and also slightly edit your torrc. Here are some instructions for Debian/Ubuntu [3]: ----- Let's start by slightly editing your regular Tor torrc to enable hidden service statistics. Please append the folowing to your regular torrc (not including quotes): """ HiddenServiceStatistics 1 """ Now, we need to install a bleeding edge version of Tor that can do hidden service statistics. You can either use the git master [3], or use Tor's APT repositories. The following instructions help you with the latter approach. Please start by following "Option two" of https://www.torproject.org/docs/debian so that you add the proper APT repositories and install tor and the deb.torproject.org-keyring package. Next, add the following line to your sources.lst: deb http://deb.torproject.org/torproject.org tor-nightly-master-wheezy main (you might need to replace 'wheezy' with your distribution, like you did in the previous step) Now, do # apt-get update # apt-get install tor which should upgrade your Tor to the latest nightly version., Your system Tor should now be up-to-date and able to collect hidden service statistics! Just start Tor as you normally do, using the torrc we modified above. For example you could simply do: # tor -f torrc but feel free to use your init script if you prefer that. Now just leave your relay do its thing, and keep an eye to this mailing list around mid-January 2015 for the results of our research. --- FWIW, if you are not using Debian, you can use the master branch of the official git repository: https://git.torproject.org/tor.git You will also need to edit your torrc in the same manner as the Debian instructions. Feel free to reply with any questions you have! Thanks! George Kadianakis Karsten Loesing Aaron Johnson David Goulet [1]: https://lists.torproject.org/pipermail/tor-dev/2014-December/007968.html [2]: https://trac.torproject.org/projects/tor/ticket/13192 [3]: for example see http://tor.stackexchange.com/questions/75/how-can-i-install-tor-from-the-so…

1 1

Information leak through WebRTC in FF/Chrome
by JusticeRage 02 Feb '15

02 Feb '15

Hi everyone, I'm not sure this is the place to share this, but I though some of you might want to know: an information leak has been discovered on Firefox / Chrome, and it can be used to reveal a user's real IP address. The article is focused on VPN, but people who connect to the Tor network through a local SOCKS proxy are also affected. Demo here . -- JusticeRage

3 2

entry guard interference?
by starlight.2015q1＠binnacle.cx 01 Feb '15

01 Feb '15

A couple of months ago I hard-configured two entry nodes that I trust for my own browsing. Both are very fast, very reliable nodes on the opposite side of the Atlantic. For about 20 minutes this evening the 'tor' daemon appears to have lost connectivity to the both nodes and I could not browse via Tor. Quite a few instances of this message were logged: Jan 30 22:59:06 Tor[]: Failed to find node for hop 0 of our path. Discarding this circuit. Neither of the configured guards were restarted during the outage, and they are located in diverse networks. The BGP looking-glass routes are different except for the first hop, which is a massive AS aggregation presumably for a trans-Atlantic cable operated by AS1299 (Telianet). I presume that this "cable" is actually a fully redundant load-balanced set of cables and any outage would be measured in milliseconds, or at most two or three seconds. Looking now, I see roughly 200 occurrences of the above message on Jan 14, 26 and 30. The reason I hard-coded the guard nodes was that, after extending the guard lifetime to 18 months, the guards were changing fairly often anyway. This bothered me. So the slightly paranoid side of my personality wonders if this is the result of a determined effort by one of the various spooky organizations out there purposefully disrupting Tor connections with the intent of forcing guard reassignment, naturally with the idea that Tor users might end up selecting guard nodes controlled by same said spooky organizations. Thoughts, comments and sharing of similar experiences are all welcome.

2 6

Re: [tor-relays] Digital Ocean: Moving to better Plan (Abhiram Chintangal)
by Spencer Rhodes 01 Feb '15

01 Feb '15

> > > I have been running a tor middle relay[1] for the past few months. > > One thing that I noticed in the last two months is that my relay is eating > up the 1tb bandwidth in the first three weeks. So I am thinking of moving > to a better plan or tweaking the current config to serve the bandwidth so > that the relay is up for the entire month. > > I assume that you want a recommendation. A better plan probably means spending more money. Would be better for the network. If you can spare the money, go for it. > > If you dont want to spend more money than it would be a good idea to lower the Rate value until you end up within your traffic limit for the month. The benefit would be a permanent available relay. > > Hmm, I think I will try changing the rate and see what happens. Last year, I used a daily limit instead of monthly one. It drastically reduced the relays reported bandwidth ( 1Mbps to 60 kbps ). > If you are on the 1TB plan at DigitalOcean, you will want to set something like the following: RelayBandwidthRate 600 KB # Throttle traffic to 600KB/s RelayBandwidthBurst 1.2 MB # But allow bursts up to 1.2 MB/s rather than set a daily or monthly limit. The reason being that your server will stay up all the time instead of suddenly hibernating (essentially going offline) when it hits the cap.

3 2

Re: [tor-relays] moving digital ocean
by Jan Nielsen 31 Jan '15

31 Jan '15

Digital ocean does not currently charge for going over your data limit. On Jan 31, 2015 1:51 PM, <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: entry guard interference? (starlight.2015q1(a)binnacle.cx) > 2. Re: entry guard interference? (starlight.2015q1(a)binnacle.cx) > 3. Re: Digital Ocean: Moving to better Plan (Abhiram Chintangal) > 4. Re: Consensus weight dropped (Bram de Boer) > 5. Re: Consensus weight dropped (starlight.2015q1(a)binnacle.cx) > 6. Re: Consensus weight dropped (starlight.2015q1(a)binnacle.cx) > 7. Re: Consensus weight dropped (Network Operations Center) > > > ---------- Forwarded message ---------- > From: starlight.2015q1(a)binnacle.cx > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 09:26:24 -0500 > Subject: Re: [tor-relays] entry guard interference? > At 06:20 1/31/2015 -0500, grarpamp wrote: > >Yet during the time of an outage, you might try > >to leave the old tor running and. . . > > I see the idea here but it's a lot > of fiddling and preparation. If it > continues to happen and I suspect > a bug, I'll upgrade the relay > version and run 'tcpdump' with > a ring-buffer capture that holds > the last two or three hours of > traffic. Then I just have to > stop the 'tcpdump' and review what > happened. Look for ICMP "not > reachable," injected RST's etc. > > If my "just because your paranoid > doesn't mean they're not out to > get you" theory is correct, it > may never happen again. Certainly > the spooks of the world all read > the Tor mailing lists. > > > > > ---------- Forwarded message ---------- > From: starlight.2015q1(a)binnacle.cx > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 10:04:14 -0500 > Subject: Re: [tor-relays] entry guard interference? > At 06:20 1/31/2015 -0500, grarpamp wrote: > >Yet during the time of an outage, you might try > >to leave the old tor running and. . . > > Also I see I should make a copy of the > cached-* files and the state file in > case some anomaly is present the Tor > routing data. > > I did look at Vidalia'a network map > at the time of the incident and the > list of relays on the left side looked > ok. On the right side something like > > <path> > <path> > etc > > appeared where client connections > normally are listed. > > > > > ---------- Forwarded message ---------- > From: Abhiram Chintangal <abhiram.chintangal(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 12:22:42 -0500 > Subject: Re: [tor-relays] Digital Ocean: Moving to better Plan > Hello Sebastian, > > Thanks for responding. > > On Fri, Jan 30, 2015 at 10:15 PM, Sebastian Urbach <sebastian(a)urbach.org> > wrote: > >> On January 31, 2015 2:09:14 AM Abhiram Chintangal < >> abhiram.chintangal(a)gmail.com> wrote: >> >> Hi Abhiram, >> >> >>> I have been running a tor middle relay[1] for the past few months. >>> >> >> Thank you very much ! >> >> >>> One thing that I noticed in the last two months is that my relay is >>> eating >>> up the 1tb bandwidth in the first three weeks. So I am thinking of moving >>> to a better plan or tweaking the current config to serve the bandwidth so >>> that the relay is up for the entire month. >>> >> >> I assume that you want a recommendation. A better plan probably means >> spending more money. Would be better for the network. If you can spare the >> money, go for it. >> >> If you dont want to spend more money than it would be a good idea to >> lower the Rate value until you end up within your traffic limit for the >> month. The benefit would be a permanent available relay. >> > > Hmm, I think I will try changing the rate and see what happens. Last > year, I used a daily limit instead of monthly one. It drastically reduced > the relays reported bandwidth ( 1Mbps to 60 kbps ). > > Thanks! > > > -- >> Sincerely yours / Sincères salutations / M.f.G. >> >> Sebastian Urbach >> >> ----------------------------------------- >> Religion is fundamentally opposed to >> everything I hold in veneration - courage, >> clear thinking, honesty, fairness, and, >> above all, love of the truth. >> ----------------------------------------- >> Henry Louis Mencken (1880 - 1956), >> American journalist, essayist, magazine >> editor, satirist and critic. >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > > -- > Abhiram Chintangal > > > > > ---------- Forwarded message ---------- > From: Bram de Boer <list-tor-relays(a)nosur.com> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 20:54:42 +0100 > Subject: Re: [tor-relays] Consensus weight dropped > All, > > Consensus weight of my relays and those of others is still near zero, and > not improving. For a network that attempts to break censorship, it is > peculiar that this is getting so little attention. > > Apparently a few malfunctioning bwauth systems is enough to censor > specific Tor relays. Endless research and development effort is put in > tweaking and optimizing the relay-to-relay communication, but having only > a few systems in the world that determine the consensus weight of the > entire network does not seem to trouble anyone. Wierd. > > I hope the bwauth operators can find a way to correct the problem. I am > feeling silly spending good money on a high-end server with unmetered > bandwidth that has now been relaying a whopping 300 Kb/s on average during > the last five weeks. > > Thanks, > Bram > > > > Thank you all for looking into this. > > > > Karsten wrote: > >> You could start a second relay on the same physical machine on a > >> different port and see whether the bandwidth scanners pick that up. > >> Give it a day or two, and see if only tor26 and moria1 measure it. > > > > In fact, both the 7C3AE76BB9E9E6E4F2AE9270FD824DF54A944127 and > > E6D740ABFFAAAD8052EDF95B2C8DC4059763F365 relays operate on the same IP > > address. Both dropped to 0.000000%. > > > > However, other nodes in the same AS16265 are doing fine (e.g. > > B144DC5C08AF1FB3ABD729AFC2CF938CF63F78AC). This seems to suggest that the > > route between the bwauths and the relay is irrelevant and connectivity is > > not an issue. > > > > I can imagine that an overloaded bwauth occasionally skips a few relays. > > But wouldn't that be corrected automatically during the measurement the > > next day? Given that the relays are missing votes consistently during > many > > consecutive days, some other mechanism must be causing this. > > > > Would a quick-fix be to randomize the order in which relays are measured? > > That way, if a bwauth has trouble processing the entire list in 24h, > every > > day other relays are given a chance? > > > > Thanks, > > Bram > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > > > ---------- Forwarded message ---------- > From: starlight.2015q1(a)binnacle.cx > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 15:23:08 -0500 > Subject: Re: [tor-relays] Consensus weight dropped > At 20:54 1/31/2015 +0100, you wrote: > >Consensus weight of my relays and those of others > >is still near zero, and not improving. . . > > I read the earlier discussion around this > issue with interest. Have no specific > ideas about resolving the problem, but > I can recommend pulling the raw text > data files for the authority votes, > grep'ping your nodes, and looking at > the specific BWauth votes over time. > > The data is found here > > https://collector.torproject.org/archive/relay-descriptors/votes/ > > and while the files are a bit huge, > are easy to whack at with *nix > command line tools such as > egrep/awk/sed/perl etc. In a > pinch one might apply Excel to the > problem, but first trim the data > set down to size with a grep or your > desktop and Excel will choke and > die. > > I did this at the point where the > bandwidth for election to guard > status was increased greatly and > my node was shipped off to middle- > relay mediocrity. Could see > clearly how it all transpired, but > of course I could do nothing about > it short of spending more $$ on > bandwidth. > > With the raw data in hand, it will > be easier to campaign the operators > of the troublesome BWauths to correct > the problem. > > > > > ---------- Forwarded message ---------- > From: starlight.2015q1(a)binnacle.cx > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 15:32:23 -0500 > Subject: Re: [tor-relays] Consensus weight dropped > also, for recent data. . . > > https://collector.torproject.org/recent/ > > > > > ---------- Forwarded message ---------- > From: Network Operations Center <noc(a)schokomil.ch> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 21:51:12 +0100 > Subject: Re: [tor-relays] Consensus weight dropped > This has already been done. And I was under the impression that things > would be changing soon. I still find it weird that the network is ignoring > several nodes. > > On 31.01.2015 09:23 PM, starlight.2015q1(a)binnacle.cx wrote: > >> At 20:54 1/31/2015 +0100, you wrote: >> >>> Consensus weight of my relays and those of others >>> is still near zero, and not improving. . . >>> >> >> I read the earlier discussion around this >> issue with interest. Have no specific >> ideas about resolving the problem, but >> I can recommend pulling the raw text >> data files for the authority votes, >> grep'ping your nodes, and looking at >> the specific BWauth votes over time. >> >> The data is found here >> >> https://collector.torproject.org/archive/relay-descriptors/votes/ >> >> and while the files are a bit huge, >> are easy to whack at with *nix >> command line tools such as >> egrep/awk/sed/perl etc. In a >> pinch one might apply Excel to the >> problem, but first trim the data >> set down to size with a grep or your >> desktop and Excel will choke and >> die. >> >> I did this at the point where the >> bandwidth for election to guard >> status was increased greatly and >> my node was shipped off to middle- >> relay mediocrity. Could see >> clearly how it all transpired, but >> of course I could do nothing about >> it short of spending more $$ on >> bandwidth. >> >> With the raw data in hand, it will >> be easier to campaign the operators >> of the troublesome BWauths to correct >> the problem. >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

1 0

Re: [tor-relays] Consensus weight dropped
by starlight.2015q1＠binnacle.cx 31 Jan '15

31 Jan '15

At 20:54 1/31/2015 +0100, you wrote: >Consensus weight of my relays and those of others >is still near zero, and not improving. . . I read the earlier discussion around this issue with interest. Have no specific ideas about resolving the problem, but I can recommend pulling the raw text data files for the authority votes, grep'ping your nodes, and looking at the specific BWauth votes over time. The data is found here https://collector.torproject.org/archive/relay-descriptors/votes/ and while the files are a bit huge, are easy to whack at with *nix command line tools such as egrep/awk/sed/perl etc. In a pinch one might apply Excel to the problem, but first trim the data set down to size with a grep or your desktop and Excel will choke and die. I did this at the point where the bandwidth for election to guard status was increased greatly and my node was shipped off to middle- relay mediocrity. Could see clearly how it all transpired, but of course I could do nothing about it short of spending more $$ on bandwidth. With the raw data in hand, it will be easier to campaign the operators of the troublesome BWauths to correct the problem.

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays January 2015