Re: [tor-relays] Usability Improvements for Atlas (was Re: Globe is now retired)
> On 30 Jun 2016, at 07:32, Green Dream <greendream...@gmail.com> wrote: > > Minor issue: there's no need to have the Show XXX entries dropdown on the > "Top 10 Relays" page (https://irl.github.io/atlas/#/top10) since it's > designed to show only 10. In fact changing the selection does nothing. This issue also exists for the Authorities page. (And if there are ever more than 10 of them, we'd want to show all of them, not just the top 10.) > On Wed, Jun 29, 2016 at 1:05 PM, Iain R. Learmonth <i...@torproject.org> > wrote: > Hi All, > > On 29/06/16 09:56, Karsten Loesing wrote: > > tl;dr: Globe is now retired in favor of an improved Atlas. > > Atlas is improved, but I'd like to improve it further. I've been > tackling #6787 looking to improve the homepage and make Atlas easier to > use for someone that isn't already a Tor expert. > > The changes I'm proposing in my fix for #6787 [1] do make some > noticeable UI changes and I just want to gather some opinions on whether > or not Atlas users feel that this is taking it in the right direction. > > The "Top 10 Relays" page was added to Atlas in order to make sure that > functionality was not lost when shutting down globe. (See #5430 [2]) > > In my proposed patch, I'm also adding an "Authorities" page and adding > text to both of these pages to explain what you're seeing. These are > linked from the homepage, and from the top navbar. > > I'm also moving the introduction and explanation of the Atlas features > from the About page to the homepage and introducing a new Help page that > explains the details that are found in the relay details pages. > > You can find a live example of this patch at: > > https://irl.github.io/atlas/#/ > > and a full list of changes are detailed in #6787. > > Please let me know if you can see any reason to not merge this, or if > you have any suggestions for small changes before merging. > > Thanks, > Iain. > > [1]: https://trac.torproject.org/projects/tor/ticket/5430 > [2]: https://trac.torproject.org/projects/tor/ticket/6787 > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge torrc custom + socks
> On 29 Jun 2016, at 04:57, Petrusko <petru...@riseup.net> wrote: > > Hey, > > Starting to set up some Bridges behind some routers, if possible at several > locations. > > Since last time, I've found some useful informations, but I'm not 100% sure > if torrc config is ok. > So the goal is : > - bridge > - obsfproxy to help censored people > - SOCKS available for LAN computers, to redirect traffic to Tor > > Here the torrc file I've tuned : > START > SocksPort 192.168.1.10:9050 #LAN IP > SocksPolicy accept 192.168.1.0/24 #Socks available for LAN computers > SocksPolicy accept 127.0.0.1 #Socks available for localhost too > SocksPolicy reject * > Log notice file /var/log/tor/notices.log > ORPort 1 > Address x.x.x.x #WAN IP > Nickname Test01 #name of the bridge node > ContactInfo m...@mail.com > DirPort 10001 > ExitPolicy reject *:* > BridgeRelay 1 > PublishServerDescriptor bridge > AuthoritativeDirectory 1 > BridgeAuthoritativeDir 1 You really don't want these two lines, they make your relay try to be an authoritative directory. > ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed > ServerTransportListenAddr obfs3 0.0.0.0:10002 > ExtORPort auto > END > > In the router/box, I'll open/forward those 3 TCP ports from the WAN to the > LAN server IP : > ORPort : 1 > DirPort : 10001 > Obfs : 10002 > > Test with a LAN client Firefox connecting with Socks is ok, IP seen is a Tor > exit... > Torcheck says the current browser is using Tor. > > But how to know if censored people can use this bridge ? (I'll test it from > an open wifi hotspot in future...) > Is this one is available in the list at bridges.torproject.org ? > I see some log lines about stats files... where will it possible to check > this bridge utilization ? > > If someone wants to correct this torrc file, please don't hesitate ! > Is there something to add, to remove ?! Another eye is always cool to be sure > ! > > Many thx for your lights :) > > -- > Petrusko > PubKey EBE23AE5 > C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5 > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious relays
Dear Nepenthes Development Team, Do you know anything about the 55 Tor Relays called "Relay127001"? https://atlas.torproject.org/#search/Relay127001 They appeared around the 23rd of June 2016. It looks like the relays have a self-signed HTTPS certificate called "Nepenthes Development Team" on port 443. If you know about these relays, there are a few things you can do to help the Tor network: * let us know if the relays are doing anything other than relaying traffic * provide a ContactInfo in the torrc, typically an email address * declare the relays to be part of a family using "MyFamily fingerprint0, … fingerprint54" in the torrc Previous discussion on the tor-relays list is below: > On 24 Jun 2016, at 16:44, simon <kom...@kalidasa.klamath.ch> wrote: > > On 23.06.2016 22:47, yandere...@riseup.net wrote: >> I check torstatus/atlas regularly and this was showing up : >> https://atlas.torproject.org/#search/Relay127001 i just thought i report >> it here. > I copypasted some of the IP addresses into my webbrowser's url bar to > check for a dirfrontpage; but what actually shows up is > "Directory listing for /" > for several of them. None of them have a DirPort, so Tor won't serve any front page. You're seeing the output from some other web server running on port 80. No identifying headers. It looks like a very basic server that serves HTML 3.2. The HTTPS is more interesting: a self-signed "Nepenthes Development Team" certificate. It's apparently a malware collection platform that "emulates only the vulnerable parts of a service". Here's the relevant paper: https://www1.cs.fau.de/filepool/publications/collecting-malware-final.pdf > I've seen something similar for "involuntary" FTP servers before. Bonnet? Or a honeypot. Or a series of cloned servers. It's hard to tell. But there do seem to be a large number of them, 55 in a recent consensus. And no contact info, either. We might want to remove these relays from the network before they pick up too many more flags. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Multiple fingerprints for same IP:Port combo
> On 22 Jun 2016, at 21:43, simon <kom...@kalidasa.klamath.ch> wrote: > > Hi, > > Is it possible to have multiple Tor-nodes (with different keypair and > fingerprint) at the same IP-Port combination? Or does that not work with > the Directory implementation? In general, no, because it violates the relay authenticity guarantee that the process you're talking to owns the private keys corresponding to the fingerprint in the consensus. Tor will warn pretty loudly if it gets a key with a different fingerprint from the one in the consensus. > The idea would be to have nodes under an anycast IP, because the anycast > network has a lot of unused capacity. It would be great to think about how any cast could work with Tor, but I suspect we've baked in a lot of assumptions about IP addresses into the Tor code, and even the Tor security design. > Another possibilty is to replicate the same node and re-use the same > keypair in multiple physical locations for the same anycast IP, but I'm > not sure this is a good idea. It would make the keys more vulnerable, and it also interferes with Tor's canonical connection code. (And likely other code that assumes 1 key = 1 IPv4.) Tim > > Simon > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 18 Dec 2015, at 02:03, Logforme <m7...@abc.se> wrote: > > My relay, Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC34), is not on > the list even though it fits all the criteria, except the HSDir flag > which I lost when I upgraded to the latest version. > Hint, hint, Mr Roger "We should somehow teach everybody that losing > their flags for a few days is totally fine" Dingledine :) > > Anyhow, I'm glad to opt in my relay if you'll have it Hi, Your relay changed its IPv4 address on around 2016-06-16 at 12:00:00. This makes it unsuitable as a fallback directory mirror. Is the new address permanent for the next two years? If so, we can add it to the list for consideration in 0.2.9. Tim > > On 2015-12-17 15:07, Nick Mathewson wrote: >> TL;DR: Stable non-exit relays can help tor clients use the Tor >> network. Please opt-in! >> >> > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Fingerprint Changed After Updates
> On 12 Jun 2016, at 03:10, Brian Kroll <br...@fiberoverethernet.com> wrote: > > Hi All, > > I had a weird event happen where the fingerprint of my relay changed > after updates to the OS. It sounds like your data directory was either erased, or configured to be a different directory. Did you make a backup before the updates? Also, since your relay was on the fallback directory list for 0.2.8.4-rc, and its fingerprint has changed, we're going to remove it. Once you've sorted out this issue, let me know, and I'll put it on the whitelist for consideration in 0.2.9. Tim > The host is running Debian 8.3 and the Tor > version was at 0.2.7.6 at the time of update. Apt was used to update > packages and the following packages were installed/upgraded. > > libapt-inst1.5:amd64 (1.0.9.8.3) > libssl1.0.0:amd64 (1.0.1t-1+deb8u2) > libidn11:amd64 (1.29-1+deb8u1) > libtasn1-6:amd64 (4.2-3+deb8u2) > libxml2:amd64 (2.9.1+dfsg1-5+deb8u2) > libcairo2:amd64 (1.14.0-2.1+deb8u1) > libexpat1:amd64 (2.1.0-6+deb8u3) > libglib2.0-0:amd64 (2.42.1-1+b1) > libgdk-pixbuf2.0-common (2.31.1-2+deb8u5) > libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u5) > libgtk2.0-common (2.24.25-3+deb8u1) > libgtk2.0-0:amd64 (2.24.25-3+deb8u1) > libgtk2.0-bin (2.24.25-3+deb8u1) > libnettle4:amd64 (2.7.1-5+deb8u1) > libhogweed2:amd64 (2.7.1-5+deb8u1) > libksba8:amd64 (1.3.2-1+deb8u1) > apt-utils (1.0.9.8.3) > libxapian22 (1.2.19-1+deb8u1) > locales (2.19-18+deb8u4) > openssh-client (1:6.7p1-5+deb8u2) > openssh-sftp-server (1:6.7p1-5+deb8u2) > openssh-server (1:6.7p1-5+deb8u2) > openssl (1.0.1t-1+deb8u2) > > After the updates completed I checked on the status of the relay and > noticed that it was not running and started the Tor process again. After > starting the process the fingerprint changed. > > My relay BrownLine was 9504CB22EEB25D344DE63CB7A6F2C46F895C3686 and now > after updates is 9C8A123081EFBE022EF795630F447839DDFDDDEC. > > I have looked through Tor logs and can find nothing of value but > heartbeat notices. I have also reviewed system logs and can find nothing > out of the ordinary. > > Any thoughts on this? Any help would be appreciated. I will also open a > bug report if needed. > > Thanks! > > //Brian > <0x5E17D55A.asc>___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Fwd: Enable relay as trusted directory & entry guard
> Begin forwarded message: > > From: Austin Holiday <aholi...@yahoo.com> > Subject: Enable relay as trusted directory & entry guard > Date: 25 May 2016 at 23:24:42 GMT-3 > > Hi, > > I have the extra capacity/bandwidth would like to upgrade my relay to an > entry node and directory server: > https://atlas.torproject.org/#details/1523C502A9754B6B42CCA5EB402A833CFF0E402D > > Is there anything I need to do? Hi, This question is best answered on the tor-relays list, I've cc'd the reply there. Your relay may be recommended as a "Guard" (entry node) by the directory authorities if it has enough stability and bandwidth over time. For more information, please read: https://blog.torproject.org/blog/lifecycle-of-a-new-relay Your relay is already a directory mirror, because you have configured a DirPort. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] TOR router install without access to root
> On 25 May 2016, at 05:46, Sebastian Niehaus <nieh...@web.de> wrote: > > Am 25.05.2016 um 10:28 schrieb Markus Koch: >> Thank you. What about the config filez in /etc/tor/ ... /etc/ should be root >> only? > > The user runnng tor must be able to read them. $DataDir has to be rw There torrc file can be in a read-only location and is -f on the command-line. The other read-only files all have individual config options that allow you to place them in /etc. The default tor DataDirectory is read-write and in /var. You can put these all in your user directory if you want, just change the tor startup script and torrc. Tim > > Sebastian > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New month, new TOR exit servers, need ELI5 pls
> On 22 May 2016, at 11:30, Random Tor Node Operator <t...@unterderbruecke.de> > wrote: > > On 05/22/2016 04:00 PM, Markus Koch wrote: >> Yes, but how many ports do I have to open to be "useful"? In an >> extreme case: Would it help just to forward port 80 and 433? > > I think the most spartanic Exit Policy is at the bottom of [1]: > > ExitPolicy accept *:53# DNS > ExitPolicy accept *:80# HTTP > ExitPolicy accept *:443 # HTTPS > ExitPolicy reject *:* > > > What is useful and what isn't is probably a matter of the eye of the > beholder. > > In my opinion, a http/https/dns-only exit is surely still more useful > than not exiting at all. It's worth noting that Exits do DNS on behalf of clients that ask to connect to a domain name, regardless of whether the ExitPolicy includes port 53. So port 53 is only useful for clients that want to run their own DNS over TCP, or use port 53 for something else. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] What's this Abuse
> On 20 May 2016, at 11:52, Dr Gerard Bulger <ger...@bulger.co.uk> wrote: > > Point taken. Can admin remove my post? No, we don't censor our own archives, and we can't censor other public archives. > > > > > -Original Message- > From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf > Of Tim Wilson-Brown - teor > Sent: 20 May 2016 16:49 > To: tor-relays@lists.torproject.org > Subject: Re: [tor-relays] What's this Abuse > > >> On 20 May 2016, at 11:12, Dr Gerard Bulger <ger...@bulger.co.uk> wrote: >> >> >> My ISP got a weird Abuse notice with no details. Just said stop. Stop what? >> When we asked what the “abuse” was they sent a 1mb.gz snapshop of their log >> files. >> >> There were a few references to my IP, but I have no idea what was seen as >> abuse:Can anyone tell me what they are fussed about?I like to >> respond in a robust manner. >> >> My IP is 5.77.47.142 > > Hi Gerard, > > It looks like the website that sent you their logs didn't filter out other > people's IP addresses. > This reduces the privacy of the users of that website. > > Please be careful when posting logs like this. > The logs you posted link users' IP addresses and their web browsing. > > One of Tor's goals is to make it difficult to link Internet users' IP > addresses and their Internet traffic. > We don't want our mailing list messages to go against this goal. > (Even if the Internet users involved are not using Tor or another IP > anonymisation method.) > > Tim > > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP 968F094B > ricochet:ekmygaiu4rzgsk6n > > > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] What's this Abuse
> On 20 May 2016, at 11:12, Dr Gerard Bulger <ger...@bulger.co.uk> wrote: > > > My ISP got a weird Abuse notice with no details. Just said stop. Stop what? > When we asked what the “abuse” was they sent a 1mb.gz snapshop of their log > files. > > There were a few references to my IP, but I have no idea what was seen as > abuse:Can anyone tell me what they are fussed about?I like to respond > in a robust manner. > > My IP is 5.77.47.142 Hi Gerard, It looks like the website that sent you their logs didn't filter out other people's IP addresses. This reduces the privacy of the users of that website. Please be careful when posting logs like this. The logs you posted link users' IP addresses and their web browsing. One of Tor's goals is to make it difficult to link Internet users' IP addresses and their Internet traffic. We don't want our mailing list messages to go against this goal. (Even if the Internet users involved are not using Tor or another IP anonymisation method.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] "support team" address?
> On 2 May 2016, at 09:51, eliaz <el...@riseup.net> wrote: > >> On 5/1/2016 4:52:12 AM, Tim Wilson-Brown - teor (teor2...@gmail.com) wrote: >>>> On 1 May 2016, at 16:52, eliaz <el...@riseup.net> wrote: >>> =20 >>> =20 >>>> On 4/30/2016 7:33:26 PM, Moritz Bartl (mor...@torservers.net) wrote: >>>>> On 04/30/2016 04:51 PM, eliaz wrote: >>>>> I'm having crashes when restarting tor. I get the error message "Tor >>>>> unexpectedly exited Send a copy of Your Tor Log to the support >>>>> team." So, what's the address? >>>> =20 >>>> This is the list for relay operation, not Tor Browser questions. = >> There >>>> is currently no good list for support questions, but tor-talk is a >>>> better "catch all" than tor-relays. >>> [snip] >>> =20 >>> I neglected to mention that tor crashes upon restart when I'm running = >> my >>> bridge. Restarting in client mode works fine. So should I send the >>> details to tor-talk or tor-relays? >> >> Please log a bug at https://trac.torproject.org and email the tor-dev = >> list about the bug number. >> It's the best way to collect details about crashes. > > Thanks Tim. I'll do that after I determine under which conditions the > crash & recovery are reproducible. I don't know when I'll be able to > make time for that, as the recovery seems to require a lot of steps, > some of which may in fact not be necessary. - eliaz Posting the last few lines of your bridge log to this list would also be useful. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] "support team" address?
> On 1 May 2016, at 16:52, eliaz <el...@riseup.net> wrote: > > >> On 4/30/2016 7:33:26 PM, Moritz Bartl (mor...@torservers.net) wrote: >>> On 04/30/2016 04:51 PM, eliaz wrote: >>> I'm having crashes when restarting tor. I get the error message "Tor >>> unexpectedly exited Send a copy of Your Tor Log to the support >>> team." So, what's the address? >> >> This is the list for relay operation, not Tor Browser questions. There >> is currently no good list for support questions, but tor-talk is a >> better "catch all" than tor-relays. > [snip] > > I neglected to mention that tor crashes upon restart when I'm running my > bridge. Restarting in client mode works fine. So should I send the > details to tor-talk or tor-relays? Please log a bug at https://trac.torproject.org and email the tor-dev list about the bug number. It's the best way to collect details about crashes. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Announcing a shutdown of a relay
> On 28 Apr 2016, at 19:17, Josef 'veloc1ty' Stautner <he...@veloc1ty.de> wrote: > > Hi @all, > > can I announce the shutdown of my relay to the network so clients select > a new guard? When you send a SIGINT to tor, tor refuses new circuits, and waits ShutdownWaitLength (default 30 seconds) for clients to choose a new guard. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] I am failing with newbie stuff :((((
> On 20 Apr 2016, at 22:35, Markus Koch <niftybu...@googlemail.com> wrote: > > hi there, > > just got 3 new didiservers and would like to move my old tor nodes > over to the brand new hardware. I am running the latest Debian > version. I copied /etc/tor/* and /var/lib/tor/* to the new servers. I > thought this should do the trick that I get the same key etc and Tor > will think this is my old node but with a new IP? It doesnt, whats my > mistake? Has tor created new keys? If so, it's likely you failed to copy the key file(s) due to ownership or permission issues on the source or destination. Does tor start as a client? If so, it's likely that you failed to copy the torrc file. Does tor fail to start? If so, it helps to let us know the warning messages it prints out. Perhaps the files were corrupted on the way, or something else happened. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reading check.torproject
> On 18 Apr 2016, at 14:14, eliaz <el...@riseup.net> wrote:
>
> In looking at the check.torproject.org page on the browser/machine that
> runs my bridge, I'm used to seeing the same IP address a.b.c.d on the
> check page ("Your IP address appears to be: a.b.c.d") as in the exit on
> the path drop-down. But today for several hours a.b.c.d showed on the
> drop-down but a different address w.x.y.z appeared on the page. Opening
> up atlas gave a "no results" error until I entered a.b.c.d manually; and
> w.x.y.z was no tor node; it turned out to belong to a VPN provider which
> was also poking my ports. Is this discrepancy normal? Should be worried
> about it? - eliaz
This sounds like it could be a bad exit redirecting all your traffic through a
VPN, while trying to attack you.
It's somewhat less likely to be a misconfiguration of the proxy settings on
your bridge.
It's normal for tor to change exits occasionally.
Do you know which exit your tor client was actually using during that time?
If so, report it to bad-rel...@lists.torproject.org
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 18 Dec 2015, at 23:12, hwertiout...@safe-mail.net wrote: > > Hi. > >> TL;DR: Stable non-exit relays can help tor clients use the Tor >> network. Please opt-in! > > My relay is on the list and I want to opt in! > > eriador 6DE61A6F72C1E5418A66BFED80DFB63E4C77668F Dear hwertiout695, It looks like your relay's IP address recently changed from 85.25.138.93 to 91.121.84.137. This is OK, we expected some fallback churn, which is why we have 100 in the list. Changing a fallback's IP address has two impacts: * Clients on 0.2.8-alpha will look for your relay as a fallback directory on the old IP address, * In 0.2.8-rc, your relay was excluded as a fallback because the IP address had changed. Will you be keeping the new IP address for the next 2 years? If so, I'll update the fallback list with the new IP address, and your relay will be considered as a fallback when we next rebuild the list. Thanks Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Relays Support of tor-relays Digest, Vol 63, Issue 20
> On 11 Apr 2016, at 16:19, Milica Đekić <milicadjeki...@gmail.com> wrote: > > Would Tor relays work in a dynamic manner switching from one to another > from time to time? I am at the beginning of my research regarding a Tor > network and I could use some support from you, guys. I would read a bit > about entry, middle and exit relays as well as layers of encryption, but I > need more realistic explaination how all of these operate in a practice. > Thank you! What have you read so far? Have you read: "Tor: The Second-Generation Onion Router"? http://www.onion-router.net/Publications/tor-design.pdf Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Private Tor Research Network
> On 9 Apr 2016, at 04:21, Nicholas R. Parker (RIT Student) <nrp7...@rit.edu> > wrote: > > Hi all, > > I've got an issue that I'm seeking help with. I'm with a small group out of > RIT that's trying to construct a private TOR network for research purposes, > but we've hit a bit of a snag. > > I've worked with both liu fengyun's > (http://liufengyun.chaos-lab.com/prog/2015/01/09/private-tor-network.html) > and Ritter's write up (https://ritter.vg/blog-run_your_own_tor_network.html), > but when trying to set up authority directories the whole thing really falls > apart. Depending on your research needs, you might find chutney helpful: https://gitweb.torproject.org/chutney.git chutney configures and launches a tor network on the local machine. It's designed to quickly smoke-test tor's key functionality, so it has a lot of torrc options set that speed things up. You should be able to get it to run using: 1. git clone https://git.torproject.org/chutney.git 2. git clone https://git.torproject.org/tor.git 3. cd tor 4. make test-network-all You might find this useful to test your code changes, or to give you a set of starting configurations that you can then modify to your own needs (including putting various nodes on different IP addresses). > Trying to edit the torrc file gives errors where it doesn't attempt to bind > to the correct ports and trying to set --dirserver or --datadirectory results > in errors that there isn't permission to access /var/lib/tor regardless of > the owner of the directory (we've tried leaving it as being owned by _tor, > tried changing ownership to root, etc) so we can't get the authority > directories off the ground. At the high level of detail your provided, these sound like typical network daemon configuration issues. Have you tried consulting a network daemon FAQ for your OS? Typically, ports under 1024 shouldn't be used, because they often require root permissions or OS-specific capabilities. Each tor authority has a configured IP and ports, and these need to be consistent in each authority, relay, and client's torrc. Multiple tor instances on the same machine should not use the same ports - this includes default ports like SOCKSPort. (Set to 0 to disable). Do you have any other services running on these machines? Do you have old tor processes still running? Typically, network daemons need to be run as the user that owns the directory (or, at the very least, the user needs permission to modify it). Have you tried using a user / permissions FAQ for your OS to help you configure the user and permissions correctly? Tor also has more specific requirements for security reasons, this protects the keys from other users on the system. It's hard to give more advice without more specific details. If this advice doesn't help, please copy and paste the configuration options you used, and the errors you got, and then tell us what you've tried to do to fix them. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] No Daily Digest Anymore
> On 8 Apr 2016, at 05:01, stea...@nym.mixmin.net wrote: > > Signed PGP part > About 2 weeks ago I stopped getting a daily digest of this list. Is > there a reason for this? Did you stop getting all emails from the list, or did it switch to individual emails? If it stopped, did emails sent to you bounce? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays with broken DirPorts
> On 2 Apr 2016, at 10:44, tor-cont...@posteo.de wrote: > > Hello, > > I'm the operator of one of the mentioned relays (81.7.14.227). Thanks, > Tim, for pointing this issue out to me. I'll try to help with this as > much as I can. > > So far, I have not been able to reproduce this issue. With the python > script from #18688, I am getting results of approx. 0.20s. It is possible that I was measuring slowdowns on my own connection, and not on the relay's connection. That's why I asked others to help me verify the issue, and work out what was going on. That said, the list of relays in "Relays with broken DirPorts" consistently failed over repeated attempts. (The relays in "Relays with very slow DirPorts" might have been slow on my end, and might just have been slow once.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays with very slow DirPorts
Dear Relay Operators, Please see below for an updated list of slow relay DirPorts. > On 31 Mar 2016, at 11:13, Tim Wilson-Brown - teor <teor2...@gmail.com> wrote: > > While I was checking fallback directory mirrors for #17158, I encountered > some relays that took more than a minute to serve a consensus. Most took 150 > seconds, which could be caused by a RelayBandwidthRate of 10 kilobytes a > second. > > One solution to this issue is to disable the DirPort on relays with a > RelayBandwidthRate less than 50 kilobytes a second, or more than 30s to serve > a consensus. > https://trac.torproject.org/projects/tor/ticket/18688 > <https://trac.torproject.org/projects/tor/ticket/18688> > (This ticket also contains the python / stem code that I'm using to check the > consensus download speed.) > > But I don't actually know if it's the relays' torrc configuration that's > causing the issue, or if their provider is limiting their speeds, or if > there's some other issue. > > If you're the operator of one of the relays listed below, can you let me know? > And if someone wants to investigate further … that would be great. It turns out that some of these relays are down, and the connections are timing out. I've modified my script so it catches timeouts, rather than treating them as "success". Here are the relays that are actually up, but timing out or producing slow DirPort directory downloads: 89.163.225.184:9030 - mertadx - No ContactInfo - 92139E58A2FD1235A9AC02B1E1E87174FB80301B 185.31.230.69:9030 - AskForEraser - cc'd - E58CECC2ED31B33867D30707CDB239C85B38FFF2 81.7.14.227:9030 - Torwell01 - cc'd - BCA197C43A44B7B9D14509637F96A45B13C233D0 62.210.238.33:9030 - ORGNorthEast1 - cc'd - FDF845FC159C0020E2BDDA120C30C5C5038F74B4 212.107.149.145:9030 - flimsy - No ContactInfo - A4B99A72464F955F7EFFB5DD968B53DD450C7FB4 (This is an incomplete list based on those relays with the highest bandwidth weights.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Relays with broken DirPorts
Dear Relay Operators, Also while working on #17158, I found some relays whose DirPort responses made my python script hang. It wouldn't even respond to ^C, but that might just be an OS X thing, or a stem thing. I'm not sure what to do about these relays. I'd like to do a tcpdump / Wireshark check, but I don't have time at the moment. Would anyone like to follow this up? This is an incomplete list of broken relay IPs and DirPorts, starting with those with the highest consensus weight: 217.23.14.190:1194 151.80.164.147:80 148.251.255.92:80 78.142.19.59:80 Thanks Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running 5000 relays...
> On 22 Mar 2016, at 08:14, Toralf Förster <toralf.foers...@gmx.de> wrote: > > Signed PGP part > Tim Wilson-Brown - teor: > > * if the AccountingRule is not "in". > Ah, > AccountingRule in > was meant. I did not set that config option in the past due to the impact of > network-in-attacks as is seen in [1]. > > Because I do have to pay just for outgoing connections I was already looking > for > AccountingRule out > in the past - is the config option implemented in 0.2.8.1-alpha ? Yes, t's in 0.2.8.1-alpha, but 0.2.8.1-alpha is unstable for relays. Please wait for 0.2.8.2. > [[AccountingRule]] **AccountingRule** **sum**|**max**|**in**|**out**:: > How we determine when our AccountingMax has been reached (when we > should hibernate) during a time interval. Set to "max" to calculate > using the higher of either the sent or received bytes (this is the > default functionality). Set to "sum" to calculate using the sent > plus received bytes. Set to "in" to calculate using only the > received bytes. Set to "out" to calculate using only the sent bytes. > (Default: max) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running 5000 relays...
> On 22 Mar 2016, at 04:22, Toralf Förster <toralf.foers...@gmx.de> wrote: > > Signed PGP part > Tim Wilson-Brown - teor: > > In 0.2.8, every relay is potentially a hidden service directory and > > a directory mirror. > But with this configuration : > > # 20 TB/month: echo "20 * 1024^4 / 31 / 24 / 60 / 60 / 1024^2" | bc > # == 8017 > # > #BandwidthRate 8 MB > AccountingMax 20 TB > > no directories are served, or ? I did say "almost all relays" later in my email, but I didn't explain the details - sorry! AccountingMax disables directory mirroring: * if the relay thinks it's likely to be exceeded, or doesn't know (the first period); and * if the AccountingRule is not "in". Relays with very low bandwidth also disable directory mirroring. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running 5000 relays...
> On 21 Mar 2016, at 21:32, tor-server-crea...@use.startmail.com wrote: > > By setting "DirPort: 0" the relays wont get flaged as Dir. So: Should be set > to 0 in this case, no? In 0.2.8, every relay is potentially a hidden service directory and a directory mirror. Clients tunnel directory connections through the ORPort. So the only thing that changes when you set the DirPort to 0 is that the port isn't opened. The details are: Hidden Service Directories (HSDir) and Directory Mirrors (V2Dir) are independent functions, with different consensus flags. HSDir: Since 0.2.7, all relays, (even if the have no DirPort) advertise in their descriptor that they are willing to be a hidden service directory. Then the authorities impose minimum uptime and bandwidth requirements for the HSDir flag. Then clients use this flag to decide whether to ask for hidden service descriptors from the relay. Directory Mirrors: In 0.2.8, almost all relays, (even if the have no DirPort) advertise in their descriptor that they are willing to accept directory connections tunnelled over their ORPort. Then 0.2.8 clients use this part of the descriptor to decide whether to make tunnelled directory connections to relays, even if they don't have the V2Dir flag. In all current releases, relays with a DirPort advertise they support the version 2 directory protocol, and then the authorities impose requirements and assign the V2Dir flag. Then clients use this flag to decide whether to make tunnelled directory connections to relays. Direct DirPort Use: Some obscure client configurations and firewalled clients may use the DirPort directly. We're looking to fix that so all client connections (and bridge connections, for consistency) are tunnelled. Relays use the DirPort directly, but they typically use the authorities for directory documents. (Some obscure relay configurations will use the fallback directory mirrors.) Tim > > > > Am Sonntag, 20. März 2016 02:54 schrieb Tim Wilson-Brown - teor > <teor2...@gmail.com>: > >> >>> On 9 Mar 2016, at 09:29, nusenu <nus...@openmailbox.org >>> <mailto:nus...@openmailbox.org>> wrote: >>> >>> - maybe run without DirPort so you do not become HSDir for to many HSes >> >> Hmm, I don't think that this will work as you expect. >> As of 0.2.7, every relay advertises that it will be a hidden service >> directory (regardless of whether it has a DirPort or not). >> This used be controlled by the HidServDirV2 option, but that's now obsolete. >> >> See ticket 16543 and commit 2f8cf524b. >> >> Tim >> >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP 968F094B >> >> teor at blah dot im >> OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exitmap module to count CloudFlare CAPTCHAs
> On 21 Mar 2016, at 04:00, Philipp Winter <p...@nymity.ch> wrote: > > I wrote an exitmap module [0] that can tell us how many exit relays see > a CloudFlare CAPTCHA when connecting to a given site. > > First, I ran the module for coreos.com because it uses CloudFlare, but > the owner configured it to whitelist Tor. Indeed, only one out of 864 > exit relays saw a CAPTCHA: > <https://atlas.torproject.org/#details/7DD29A65C370B86B5BE706EA3B1417745714C8AF> > > Next, I ran the module for cloudflare.com, which does not seem to > whitelist Tor. 638 (75%) exit relays saw a CAPTCHA and 211 (25%) > didn't. This looks great! Do we know if CloudFlare's blocking depend on the remote website, or the website's CloudFlare settings? Or does CloudFlare treat each Exit Relay the same regardless of which website it's accessing? Their introductory marketing / documentation would seem to indicate it's global: "Once CloudFlare identifies that there is a new attack, CloudFlare starts to block the attack for both the particular website and the entire community." [0] Can the ExitMap module also record how many sites show CloudFlare's "JavaScript Challenge" [1] ? http://www.zdziarski.com <http://www.zdziarski.com/> (yes, only HTTP, ugh) uses their JavaScript challenge. And their "Totally Block Tor" [1] option? (only available to enterprise (paying?) customers) I don't know of a CloudFlare website that blocks Tor entirely. Thanks Tim [0]: https://www.cloudflare.com/features-security/ <https://www.cloudflare.com/features-security/> (URL likely unavailable from some Tor Exits.) [1]: https://support.cloudflare.com/hc/en-us/articles/203306930-Does-CloudFlare-block-Tor- <https://support.cloudflare.com/hc/en-us/articles/203306930-Does-CloudFlare-block-Tor-> (URL likely unavailable from some Tor Exits.) Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running 5000 relays...
> On 9 Mar 2016, at 09:29, nusenu <nus...@openmailbox.org> wrote: > > - maybe run without DirPort so you do not become HSDir for to many HSes Hmm, I don't think that this will work as you expect. As of 0.2.7, every relay advertises that it will be a hidden service directory (regardless of whether it has a DirPort or not). This used be controlled by the HidServDirV2 option, but that's now obsolete. See ticket 16543 and commit 2f8cf524b. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] please send me your hosters
> On 20 Mar 2016, at 05:08, harvie josh <harvie.j...@inbox.ru> wrote: > > >>>> Can you add your findings to >>>> https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs ? >>> >>> I do not know what their policies on tor relays are, that is why I can >>> not really add anything new to that site. >> >> It'a always a good idea to ask. > > I don't think it is worth the effort for non-exits. Since that should not > botter the hoster at all. Some hosters are bothered by (or do not support) high numbers of connections / CPU / network use, even in supposedly "unlimited" environments. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] What IPs does Torbrowser need?
> On 16 Mar 2016, at 01:28, Martin Kepplinger <mart...@posteo.de> wrote: > > Hi > > Imagine a router that want to only whitelist the IP addresses that > Torbrowser needs to work. What IPs would it need (for start up and > browsing) ? > > * Guards During normal operation after bootstrapping. > * Authorities For bootstrapping. As of 0.2.8.1-alpha, each release has a different list of fallback directory mirrors. If they're not whitelisted, initial bootstrap will be delayed for around 10 seconds, then tor will try an authority. > * HSDir flagged relays (?) Shouldn't be required, all connections go through a 3-hop circuit that starts at a guard. > and would such a whitelisting of IPs even work? Yes, this kind of whitelisting of addresses used by tor worked quite well when I was testing the fallback directory mirror and IPv6 client bootstrap features. (I would block or allow certain addresses, then make sure tor behaved sensibly.) > At least I think DNS can > be ignored as it is routed over Tor too. Server DNS names are sent to the Tor Client as part of the SOCKS 5 protocol. The Tor Client sends the server name to the Exit. Then DNS resolution is performed by the Exit. So technically, there are no DNS packets until the Exit queries its DNS servers for the server name provided by the client. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ticket #18489
> On 9 Mar 2016, at 07:17, Roger Dingledine <a...@mit.edu> wrote: > > On Tue, Mar 08, 2016 at 09:07:07PM +0100, Felix wrote: >> Hi >> >> I stumbled over [1]. As I operate Doedel26 I checked >> DownloadExtraInfo was default. After change in torrc to 1 and reload >> 'cached-extrainfo' showed up in /var/db/tor/. >> >> Can someone please advice how to deal with it ? >> >> Best regards, Felix >> >> [1] https://trac.torproject.org/projects/tor/ticket/18489 > > I think the answer is you, the relay operator, shouldn't have to do > anything. Indeed! Thanks for reporting this issue. We released a list of fallback directories in 0.2.8.1-alpha to find issues like this. > My guess is that it's a bug in somebody's expectation for how to > implement the fallbackdirectory design. The fix might be something > like "teach clients who are trying to fetch extrainfo descs to not > ask relays who don't offer them". Yes, that would be the plan. The code that picks authorities and fallback directories uses the same function, so it looks like there are some missing flag checks. (We plan on unifying the code that picks authorities / fallback directories and the code that picks directory mirrors. If we'd managed that in 0.2.8, then these checks would be correct, because they're being performed for directory mirrors.) > Once some devs, especially teor, recover from the Valencia meeting, > I expect this one will be easy to resolve. I am still in an airport, and I believe others are still on post-dev-meeting leave. Give us a week or so to look into it. We should be able to get a fix in the next alpha. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] relay maintenance without losing consensus weight?
> On 8 Mar 2016, at 22:37, Zwiebel <zwie...@kawo2.rwth-aachen.de> wrote: > > Hello, > is there a way to shut down Tor relays for a short time without losing > consensus weight or bandwidth? This is a frequently asked question, particularly if you add "losing flags" to the relay operator's list of concerns. I wonder if it's worth adding a FAQ or wiki entry with potential answers: It takes time: * wait, and the authorities and bandwidth authorities will re-assess your relay over about a week; * clients may have given up on you as a guard, and may not come back for several months; The network is dynamic: * if the network is growing, your relay's share is going to be lower over time; * if the network is not using its full relay capacity, this is good, because packets travel faster; * (it's also good because sudden increases can be absorbed without impacting existing users); We make bug fixes and add features: * we recently fixed a bug where a relay would submit a descriptor with an 0 DirPort when it restarted (0.2.7.7 [unreleased], 0.2.8.1-alpha); * in 0.2.8, network load is moved from the authorities to fallback directory mirrors, please opt-in if your relay is stable; * in 0.2.8, network load is moved from directory mirrors with DirPorts, to almost all relays via tunnelled directory connections. Depending on your relay's role in the network, it might see more or less traffic with these changes. > Last week I installed a newer Tor version and added more RAM and now my > relays lost a third of their bandwidth. Last time I've upgraded the > hardware was in January and the relays didn't fully recover from the downtime > in the last two months. I'd gladly provide 200Mb/s+ of relay bandwidth if I > could, but Tor won't let me. Networks need extra capacity - it increases average speeds, and absorbs sudden usage spikes. Consider starting a second tor instance on other ports to use the extra capacity on your server. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor-relays Digest, Vol 61, Issue 41
> On 28 Feb 2016, at 21:17, stea...@nym.mixmin.net wrote: > > > Is your OpenSSL compiled optimised for your processor and for the > > encryption that Tor uses? > > > > I am using the OpenSSL that was compiled for my version of > Mixmaster as I am running a middle remailer on the same VPS. It is > OpenSSL: 1.0.1e Does Tor log a message when it starts recommending an optimised version of OpenSSL? > > How much RAM does your VPS have? > 512KB This is likely to be your issue. 512 MB is not enough for a large relay. Tor will limit its memory and connections to stay under about 3/4 of the memory you have. Try 1GB. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] biggest guard operator apparently left the tor network
> On 28 Feb 2016, at 15:46, SuperSluether <supersluet...@gmail.com> wrote: > > From what I understand, the 3% that was lost should eventually be distributed > to the remaining relays, correct? Within a very short period of time, clients will use other guards. They'll try guards they have previously chosen, and try new guards if all previously chosen guards are down. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Network Bandwidth Fine Tuning
> On 28 Feb 2016, at 02:14, stea...@nym.mixmin.net wrote: > > Signed PGP part > I ran the speedtest on my VPS which gave the results below: > > root$ speedtest-cli > Retrieving speedtest.net configuration... > Retrieving speedtest.net server list... > Testing from ProServe B.V. (81.4.111.251)... > Selecting best server based on latency... > Hosted by NFOrce Entertainment B.V. (Amsterdam) [0.00 km]: 4.817 ms > Testing download speed > Download: 711.10 Mbit/s > Testing upload > speed.. > Upload: 449.12 Mbit/s > > My Bandwidth results are averaging around 1.5mbs to 3.0mbs via the > Tor Globe Stats page. > > Can someone tell me how to increase my network bandwidth based on > what I am capable of uploading and downloading. I am allocated 2TB > of bandwidth per month from my VPS What processor is on your VPS? How fast is it? Does it have AES-NI? Is your OpenSSL compiled optimised for your processor and for the encryption that Tor uses? How much RAM does your VPS have? Have you read the torservers.net Tor tuning advice? (And similar articles?) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Feedback
> On 26 Feb 2016, at 11:52, Random Tor Node Operator <t...@unterderbruecke.de> > wrote: > > On 26.02.2016 05:15, torser...@datakanja.de <mailto:torser...@datakanja.de> > wrote: >> * Next, i noticed a frequent (daily) behavior of the Tor server >>dropping traffic to around zero. Inspecting this, let me to >>understand, my provider was disconnecting me and reassigning a new >>IP on a daily basis, which took some time to propagate. Even worse: >>It did not propagate on its own, i needed to restart the tor service >>to reinitialise... > > > Instead of a Tor Relay, you can operate a Tor Bridge, perhaps with obfs4. > A regularly changing IP address is less of a problem for bridges. It may > even be of advantage. Once its IP address gets blacklisted by > adversarial actors, you already have a new one. But how do users find that new address? (For some users, the bridge authority might tell them when provided with the bridge's fingerprint, but only if their other bridges work.) > (Of course they could > still simply block the whole /16 or whatever your ISP has) Typically only the IP and port are blocked. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Feedback
Hi, > On 26 Feb 2016, at 05:15, torser...@datakanja.de wrote: > > * Next, i noticed a frequent (daily) behavior of the Tor server >dropping traffic to around zero. Inspecting this, let me to >understand, my provider was disconnecting me and reassigning a new >IP on a daily basis, which took some time to propagate. Even worse: >It did not propagate on its own, i needed to restart the tor service >to reinitialise… It should take tor about an hour to realise your address has changed, and another hour for it to propagate to the rest of the network. > * Asking in the online channel, i was guided to change my "Nickname" >torrc config to match the dyndns entry corresponding to my server. I hope you mean "Address" here. The "Nickname" is what your relay is called, the "Address" is where it is. > * But this never made it to the directories, thus forcing me to >manually restart Tor on a daily basis in order to force the changing >IP address into them. This could be an issue with your relay's DNS, or some of the other settings. Did you wait an hour or two? > * Finally, i was told, this behavior would be disruptive to the >network, i therefore brought the service down for good, wasting the >bandwith, i was willing to spend, for the near future. :-) That's a shame, tor will use relays that are only up for short periods of time for the middle of a circuit, and for rendezvous points for short-lived hidden service circuits. So it's not disruptive or useless. (It might slow down a few clients who try your relay for the few hours each day it takes to find its new IP address.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Stable Flag Question
> On 25 Feb 2016, at 18:30, stea...@nym.mixmin.net wrote:
>
> Signed PGP part
> I just recently had my Stable Flag removed from my middle relay. It
> appears that my stats have gotten better over the past few days, so
> it's not clear to me why the stable flag was removed. Can someone
> explain how this flag is enabled or not enabled?
>
> Relay Name: stealth
> Fingerprint: A290A9E71ADFC2FB1C80E64EF851A4B905450105
Looks like some of the authorities couldn't reach your relay ("Running") last
time they checked, and the majority doesn't think it's "Stable" (based on
uptime). Perhaps this is because it was restarted recently.
https://consensus-health.torproject.org/consensus-health.html
<https://consensus-health.torproject.org/consensus-health.html>
Perhaps it's because you changed your address or orport on 2016-02-18.
https://onionoo.torproject.org/details?search=A290A9E71ADFC2FB1C80E64EF851A4B905450105
<https://onionoo.torproject.org/details?search=A290A9E71ADFC2FB1C80E64EF851A4B905450105>
(Bug #18050 could cause this, it's fixed in master and 0.2.7, and we're
considering it for 0.2.6.)
Give it time, and enough authorities should believe your relay is stable.
Perhaps you could consider upgrading it from 0.2.4?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Mexico ISP blocking authority nodes and preventing exit relays.
> On 18 Feb 2016, at 22:16, Mirimir <miri...@riseup.net> wrote: > > On 02/18/2016 03:47 AM, Tim Wilson-Brown - teor wrote: >> >>> On 18 Feb 2016, at 14:40, Ricardo Malagon Jerez <rjmala...@gmail.com> wrote: >>> >>> I don't know how and why, but since January is impossible to have an exit >>> relay in Telmex ISP. >>> And is harder to reach authority nodes. >>> Someone wrote about this, but is mid February and is the same. >>> Tor 2.8 alpha works pretty good with the authority fallback measures, but I >>> can't implement the exit relay or publish the relay. >> >> Thanks for the feedback about the fallback directory mirrors feature - I am >> glad to hear that it's working as planned. >> But it only works for clients. >> >> Relays need to be able to post their descriptors to the authorities. So they >> have to be able to reach at least one authority - they can't use only >> fallback directory mirrors. > > Could relays somehow use bridges for that? Relays could upload their descriptors to the authorities over 3-hop tor circuits, like hidden services do to hidden service directories. But that doesn't solve the core issue: Tor assumes all relays can connect to every other relay. If a relay can't reach the authorities, then that's 9 relays it can't reach, and it's likely that other relays are also blocked. We would need to answer the following questions before we allowed relays that can't reach the authorities to bootstrap: * how many other relays can each Tor relay reach at the moment? * what's the minimum number of relays each relay should be able to reach to be useful? * how can we check if a relay can reach that many relays? * should the relay do the check itself before it submits its descriptor, or should the authorities or bandwidth authorities do the check? This requires some research and security analysis. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Mexico ISP blocking authority nodes and preventing exit relays.
> On 18 Feb 2016, at 14:40, Ricardo Malagon Jerez <rjmala...@gmail.com> wrote: > > I don't know how and why, but since January is impossible to have an exit > relay in Telmex ISP. > And is harder to reach authority nodes. > Someone wrote about this, but is mid February and is the same. > Tor 2.8 alpha works pretty good with the authority fallback measures, but I > can't implement the exit relay or publish the relay. Thanks for the feedback about the fallback directory mirrors feature - I am glad to hear that it's working as planned. But it only works for clients. Relays need to be able to post their descriptors to the authorities. So they have to be able to reach at least one authority - they can't use only fallback directory mirrors. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] TOR service wont start with ORPort enabled
> On 14 Feb 2016, at 23:05, Volker Mink <volker.m...@gmx.de> wrote: > > Hey there. > > I recently updated my working TOR Exit from Raspian Wheezy to Jessie and also > updatet my TOR-Version. > > Now I got the problem, that the TOR-service wont start when I have the ORPort > in the torrc-file enabled. > Port 9001 is forwarded at my router and the Pi is also in the DMZ. Can you please send us the Tor log messages? They usually say why Tor won't start. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Should Onionoo consider relays with the same ip# to be part of the same family?
> On 5 Feb 2016, at 21:28, Virgil Griffith <i...@virgil.gr> wrote: > > I withdraw my desire this proposal. In Roster we wouldn't want these /16 > network families---we just wanted to collapse some relays together when we > reliably believe they have the same operator, and there's no reason to > believe the majority of relays within a /16 are owned by the same person. There are known cases where relays on the same IP address happen to be using the same provider and external NAT, but have different operators. > > Ergo, Roster will forgo this kind of merging. > > -V > > On Friday, 5 February 2016, Karsten Loesing <kars...@torproject.org > <mailto:kars...@torproject.org>> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> [Removing metrics-team@ to avoid cross posting.] >> >> On 28/01/16 21:22, Tim Wilson-Brown - teor wrote: >>> >>>> On 29 Jan 2016, at 07:20, Roman Mamedov <r...@romanrm.net >>>> <mailto:r...@romanrm.net> <javascript:;>> >> wrote: >>>> >>>> On Fri, 29 Jan 2016 06:33:51 +1100 Tim Wilson-Brown - teor >>>> <teor2...@gmail.com <mailto:teor2...@gmail.com> <javascript:;>> wrote: >>>> >>>>> Tor already considers relays in the same IPv4 /16 to be in the >>>>> same family. >>>> >>>> Maybe a step further in this would be to autoextend manually >>>> declared families with all relays running on the same IPs of any >>>> relays in the family. Dunno how complex or how useful this would >>>> be. It could at least fix-up some outdated or missed >>>> declarations. >>> >>> In Tor, or OnionOO? >>> >>> Tor already does this using the IP address whenever a path is >>> built. If Tor added it on the relay side, then we'd bloat >>> descriptors for no reason. >> >> Agreed. >> >>> If OnionOO added it, it would save OnionOO clients some work. >> >> Let's consider this. I'm pasting current definitions of related >> Onionoo fields here, so that people can follow more easily: >> >> - "effective_family": Array of $-prefixed fingerprints of relays that >> are in an effective, mutual family relationship with this relay. These >> relays are part of this relay's family and they consider this relay to >> be part of their family. Omitted if empty or if descriptor containing >> this information cannot be found. >> >> - "alleged_family": Array of $-prefixed fingerprints of relays that >> are not in an effective, mutual family relationship with this relay. >> These relays are part of this relay's family but they don't consider >> this relay to be part of their family. Omitted if empty or if >> descriptor containing this information cannot be found. >> >> - "indirect_family": Array of $-prefixed fingerprints of relays that >> are not in an effective, mutual family relationship with this relay >> but that can be reached by following effective, mutual family >> relationships starting at this relay. Omitted if empty or if >> descriptor containing this information cannot be found. >> >> Now, from reading this thread I can see us adding or extending the >> following fields: >> >> - Extend "effective_family" to also include relays on the same IP >> address or in the same /16. I'd rather not want to do this, because >> we wouldn't be able to say whether that other relay is in a mutually >> declared family relationship or just runs on a nearby IP address. >> >> - Add new "network_family" field with fingerprints of all relays in >> the same /16. Plausible, but duplicates fingerprints that are already >> in "effective_family". >> >> - Add new "network_family" field with only those fingerprints of >> relays in the same /16 that are not contained in "effective_family". >> "Tor considers these relays to be part of your relay's family, because >> they have similar enough network addresses. If you are running them, >> please consider setting the family option." Plausible, though not >> trivial to grasp without further explanation. >> >> - Add new "extended_network_family" field with fingerprints of relays >> in the same /16 as this relay or relays in "effective_family" and >> "indirect_family", except for fingerprints in those two fields. Also >> plausible for the Roster use case to identify all relays close to the >
Re: [tor-relays] Nameservers fail and come back at the same time?
> On 1 Feb 2016, at 08:19, SuperSluether <supersluet...@gmail.com> wrote: > > I'm not sure how many DNS servers are configured because I never configured > them. I just installed Tor and edited the torrc file with my port, exit > policy, and bandwidth options. Where would I add/configure DNS servers? Typically, by editing /etc/resolv.conf. But some platforms automatically generate it using the files in /etc/resolvconf/resolv.conf.d/ It should be fairly straightforward, if not, search the Internet for a HOWTO for your platform. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nameservers fail and come back at the same time?
> On 1 Feb 2016, at 10:38, Tristan <supersluet...@gmail.com> wrote: > > Well, my VPS nameservers are domain names, not IP addresses, so I can't use > them directly. In the meantime, I added Open DNS to resolv.conf, but I still > get errors from Google DNS. Do I need to reboot to apply changes to > resolv.conf? > You likely need to send a HUP to tor to get it to re-read your DNS configuration. Maybe Google DNS is not reliable from your location, so you could put another name server first? Or perhaps investigate resolving your VPS DNS manually, then using their IP addresses as well? Tim > On Jan 31, 2016 3:27 PM, "Tim Wilson-Brown - teor" <teor2...@gmail.com > <mailto:teor2...@gmail.com>> wrote: > >> On 1 Feb 2016, at 08:19, SuperSluether <supersluet...@gmail.com >> <mailto:supersluet...@gmail.com>> wrote: >> >> I'm not sure how many DNS servers are configured because I never configured >> them. I just installed Tor and edited the torrc file with my port, exit >> policy, and bandwidth options. Where would I add/configure DNS servers? > > Typically, by editing /etc/resolv.conf. > But some platforms automatically generate it using the files in > /etc/resolvconf/resolv.conf.d/ > > It should be fairly straightforward, if not, search the Internet for a HOWTO > for your platform. > > Tim > > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP 968F094B > > teor at blah dot im > OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays> > > _______ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nameservers fail and come back at the same time?
> On 1 Feb 2016, at 06:33, SuperSluether <supersluet...@gmail.com> wrote: > > My exit node's consensus weight just jumped from 20 to 1750 overnight. When I > checked to see how things were going, my log file is full of nameserver > problems, happening every couple of minutes: > > Jan 31 14:12:40.000 [warn] eventdns: All nameservers have failed > Jan 31 14:12:40.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up > Jan 31 14:18:35.000 [warn] eventdns: All nameservers have failed > Jan 31 14:18:35.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up > Jan 31 14:20:53.000 [warn] eventdns: All nameservers have failed > Jan 31 14:20:53.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up > Jan 31 14:20:59.000 [warn] eventdns: All nameservers have failed > Jan 31 14:20:59.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up > > But the "All nameservers have failed" and "Nameserver xxx is back up" > messages happen in pairs at the exact same time. What's going on here, and is > there a way to fix this? My VPS has 2 nameservers listed for it, should I be > using those? The times in tor logs are anonymised by rounding to the nearest second. So these entries are close together, but not necessarily at the same time. How many DNS servers do you have configured? (It looks like it's only one. That's quite a fragile configuration.) If it fails a request by chance, but the next request succeeds, this is the pattern of messages you'll see. Try adding a local caching resolver as the first listed name server. You might want to add your VPS DNS servers, and Google's other server to the end of the list, too. (A benefit of using local DNS servers is that fewer networks see your DNS requests. A drawback is that your VPS company then sees your DNS requests and your traffic, but they could do this anyway.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] What does this message mean in my tor logs?
> On 28 Jan 2016, at 12:38, Pat Scharmer <p...@scharmer.net> wrote: > > Hi all, > > I’m running a server with a couple of relays and was getting good overall > performance (120+ Mbps) up until a couple days ago. For the last two days, > the log for one of the two relays is showing thousands of the following > message: > > [notice] Resolved [scrubbed] which was already resolved ignoring It seems that tor is getting duplicate DNS responses when it sends out a DNS query. Are your resolvers configured correctly? Have you configured a caching DNS resolver on your machine? (This has been reported to increase throughput substantially.) > Prior to yesterday, I hadn’t ever seen this message in my log (and the second > relay on this same server/same IP is not showing any such messages). Since > this started, my throughput has dropped from around 120Mbps to about 80Mbps. > Looking around on the internet, I can’t find anything about this message. My > server is running tor 2.7.6 on Ubuntu. A misconfigured DNS resolver is one of the common reasons Exit throughput drops. > The relay in question is: > https://atlas.torproject.org/#details/FE67A1BA4EF1D13A617AEFB416CB9E44331B223A > > <https://atlas.torproject.org/#details/FE67A1BA4EF1D13A617AEFB416CB9E44331B223A> Thanks for the fingerprint, Atlas confirms your relay is an Exit. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Should Onionoo consider relays with the same ip# to be part of the same family?
> On 27 Jan 2016, at 18:19, grarpamp <grarp...@gmail.com> wrote: > > On Wed, Jan 27, 2016 at 12:00 AM, Virgil Griffith <i...@virgil.gr> wrote: >> No wrong answer---just wondering what is the community's vibe on this >> issue. I can go either way. > > Same IP excepting NAT is same box, kind of pointless if > they're not the same entity [1], err to caution and call it family, > put them in touch or encourage one or both to move or shutdown. > > [1] Same entity would make sense if it was that entities > chosen / available way of binding multiple cpu cores to > tor instances, at least as far as the daemons go without > considering overall utility to tor. Tor already considers relays in the same IPv4 /16 to be in the same family. See nodelist_add_node_and_family() and addrs_in_same_network_family() in the tor source. Whether OnionOO should reflect this is another matter. Perhaps it could imitate Tor, and have a separate field called "network family"? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Should Onionoo consider relays with the same ip# to be part of the same family?
> On 29 Jan 2016, at 07:20, Roman Mamedov <r...@romanrm.net> wrote: > > On Fri, 29 Jan 2016 06:33:51 +1100 > Tim Wilson-Brown - teor <teor2...@gmail.com> wrote: > >> Tor already considers relays in the same IPv4 /16 to be in the same family. > > Maybe a step further in this would be to autoextend manually declared families > with all relays running on the same IPs of any relays in the family. Dunno how > complex or how useful this would be. It could at least fix-up some outdated or > missed declarations. In Tor, or OnionOO? Tor already does this using the IP address whenever a path is built. If Tor added it on the relay side, then we'd bloat descriptors for no reason. If OnionOO added it, it would save OnionOO clients some work. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] EventDNS error
> On 26 Jan 2016, at 01:12, TorOp AnonymizedDotIo1 <torre...@anonymized.io> > wrote: > > Hi, > > Over the weekend I started having those kind of error popping on my log at a > very high rate (a few per seconds): > > Jan 25 09:00:00.000 [warn] eventdns: Address mismatch on received DNS packet. > Apparent source was xxx.237.192.xxx:61083 > > Apparent source is not my IP and is different at every error message. I > restarted my relay and I have stopped happening. I am running my own local > unbound DNS server. > > Is it some kind of attack or simply an error that happened over the weekend? > I have never seen it before. This error is logged when Tor sends a DNS query to an address, but gets a reply back from a different address. This could be an attack, or a misconfigured DNS server, or simply a multihomed DNS server. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] Bad password or authentication cookie on controller.
> On 22 Jan 2016, at 08:33, pa011 <pa...@web.de> wrote: > > Hello, > > yesterday I got within a minute three times the above warning in my log > file on Tor 0.2.7.6. > > Could somebody please explain to me what it means and how to solve? Someone tried to login to your control port with the wrong password. Are you running a relay monitor? (It could be misconfigured.) Is your ControlPort bound to a non-loopback address? Are you running in a FreeBSD jail or OpenVZ VM? They can bind to non-loopback addresses unexpectedly. Are you running an exit? Have you set your exit policy to block all local addresses on your relay? Tor tries to find and block all local addresses, sometimes it can't discover all of them. > Is there a source where I can possibly find answers on this and other > warnings? Unfortunately, there's no reference containing all of Tor's warnings. Search the mailing lists, source code or Internet? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Revised Opt-In Trial: Fallback Directory Mirrors
> On 13 Jan 2016, at 11:21, Tim Wilson-Brown - teor <teor2...@gmail.com> wrote: >> On 13 Jan 2016, at 10:33, Tim Wilson-Brown - teor <teor2...@gmail.com >> <mailto:teor2...@gmail.com>> wrote: >>> At 19:20 1/12/2016 +0100, Aeris wrote: >>>> ... >>>> After grepping some logs, seems 13/12 was the day of a Tor >>>> upgrade : >>>> >>>> 2015-12-13 10:47:31 upgrade tor:amd64 0.2.7.5-1~d80.jessie+1 >>>> 0.2.7.6-1~d80.jessie+1 >>>> 2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1 >>>> >>>> Timing is good compare to the 10:48:46 of the consensus ! >>>> ... >>>> And perhaps the Tor reboot cause the DirPort to >>>> be temporarily disabled (seems not human, only >>>> 2s duration) ? >> >> I wonder if the DirPort self-test finished ~62 seconds after the ORPort >> self-test? >> (Or, strictly, after the first descriptor was submitted?) >> >> That would explain the behaviour we're seeing here. >> (And it shouldn't be grounds for exclusion as a fallback directory, let me >> see what I can do.) > > The fallback directory update script uses the OnionOO field > last_changed_address_or_port, which is implemented correctly: the relays in > question did stop announcing their DirPort within the last 120 days. > > In the fallback directories script, there doesn't seem to be any way to work > around the special case where relays stop announcing their DirPort for a > single descriptor/consensus because they have been restarted, and their > DirPort self-test has not finished yet. > > So I don't know if there's any way to fix this, apart from fixing the > underlying issue with the relay code, and waiting 120 days for the previous > upgrades to be old enough that they don't matter any more. I think we've resolved this issue at both ends: Relays should not experience the 0 DirPort issue when upgrading to the next 0.2.7 release. https://trac.torproject.org/projects/tor/ticket/18050 <https://trac.torproject.org/projects/tor/ticket/18050> In the 0.2.8-alpha series, we use a shorter address stability period to work around previous address changes due to the 0 DirPort bug. (This is ok, because fewer people use the alpha series, and they don't use it for very long before upgrading.) https://trac.torproject.org/projects/tor/ticket/18086 <https://trac.torproject.org/projects/tor/ticket/18086> Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 18 Jan 2016, at 11:07, Roman Mamedov <r...@romanrm.net> wrote: > > On Mon, 18 Jan 2016 10:16:40 +1100 > Tim Wilson-Brown - teor <teor2...@gmail.com> wrote: > >> I think if a client is just using it for bootstrap, any extra latency >> shouldn't be an issue. >> But IPv6 clients may also pick it as a guard, so that should be taken into >> account. >> >> Should we be running relays over IPv6 tunnels? > > Hurricane Electric has tunnel servers all over the world, so it's easy to pick > one which will only add negligible latency: > https://tunnelbroker.net/status.php > > Performance is not a concern either, these are not overloaded and should > be quite fast. > > On the other hand HE.net may or may not want to have a word with you if you > run a relay through them with hundreds of megabits of IPv6 traffic; but that's > not something we can expect in the nearest future. [and such powerful relays > are most likely in proper DCs with easily obtainable native IPv6 anyways] We're still working to get Tor clients bootstrapping over IPv6, so there isn't going to be much IPv6 relay traffic at the moment. > There's a possible privacy issue that all the HE.net tunnel traffic can > technically be captured by HE.net; > > however all of these provide IPv6 addresses under the same AS (6939) and the > same prefix of 2001:470::/32, so perhaps the same-AS avoidance code will > ensure that a HE.net IPv6 is only used once in a circuit? Does it correctly > handle cases when a router's IPv4 and IPv6 addresses are from different ASes? Tor doesn't use ASs for same-network avoidance, it only uses network masks. In the current Tor codebase, onion_populate_cpath()/addrs_in_same_network_family() avoids adding relays in the same IPv4 /16 to the same circuit. IPv6 addresses are not considered, because this check uses the relay's primary ORPort IPv4 address. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor being blocked by mayor ISP in Mexico?
> On 16 Jan 2016, at 09:08, Test This <emu.x86...@gmail.com> wrote: > > My Relay, the Tor Browser and Fire.Onion have a higher possibility to get > stuck while bootstrapping at 0, 5, 20%. Once passed the 50~60% it get faster. > My assumption is that my ISP is blocking or at least randomly dropping > packets to and from well known Tor Authorities (IP blocking). > I don't suspect DPI, as client functionality is working. > Using bridges was not necessary when trying client functionality. I was able > to connect (abort and retry). As reported by Fabian Bustillos as well. We're working on a fix for this issue, by providing tor clients with a list of fallback directory mirrors This allows clients which can't reach the directory authorities to bootstrap. (But it doesn't resolve the issue for relays, which need to be able to reach the authorities.) We're trialling fallback directory mirrors in the 0.2.8 alpha series. https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors <https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors> Another fix for this issue has clients try multiple directory authorities (or fallback directory mirrors) when bootstrapping. This makes bootstrap more reliable when only a few directory authorities are reachable. (It also doesn't help relays, because they need to be able to reach the authorities.) https://trac.torproject.org/projects/tor/ticket/4483 <https://trac.torproject.org/projects/tor/ticket/4483> Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 18 Jan 2016, at 03:05, Thom Wiggers <torli...@thomwiggers.nl> wrote: > > Hi all, > > I would like to opt in for this trail, > > My relay is: > > tornoderdednl CBEFF7BA4A4062045133C053F2D70524D8BBE5BE on 178.62.199.226 / > [2a03:b0c0:2:d0::b7:5001]. > > (Will you also be including IPv6 addresses?) Hi Thom, The current fallback directories script looks up each relay's IPv6 address from OnionOO and adds it to the relay's fallback directory entry. These addresses are parsed by Tor as of 0.2.8-alpha-dev, but clients don't use them to bootstrap yet. (I'm working on IPv6 client bootstrap in Trac Ticket #17840, hopefully it will make it into 0.2.8.) https://trac.torproject.org/projects/tor/ticket/17840 <https://trac.torproject.org/projects/tor/ticket/17840> Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 18 Dec 2015, at 04:43, t...@use.startmail.com wrote: > > Not on the list of candidate fallbacks i still offering my family: > $4B9E2C56FB42B891794FE2CD2FCAD08A320CC3BB,$BEE2317AE127EB681C5AE1551C1EA0630580638A,$F6279A203C1950ACF592322A235647A05BFBCF91,$5BFDECCE9B4A23AE14EC767C5A2C1E10558B00B9 Hi, Thanks for the opt-in, but these relays have no DirPort configured. Relays need a DirPort to act as fallback directory mirrors. If you are able to configure a DirPort on these relays, please let me know, and I'll add them to the list. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 18 Dec 2015, at 06:03, starlight.201...@binnacle.cx wrote: > > Relay 'Binnacle' experienced outages due to a > loose fiber-option junction in the overhead > wires that has been repaired. I believe > it would make the list if not for this > and do not foresee further trouble. > ... > Available if desired. Can configure IPv6 > on the HE tunnel here if helpful. Once clients start bootstrapping over IPv6[0], more IPv6 fallback directories and relays would be helpful. But I don't know enough about IPv6 tunnels in general and Hurricane Electric in particular to know whether a tunnel is advisable for a tor relay. I think if a client is just using it for bootstrap, any extra latency shouldn't be an issue. But IPv6 clients may also pick it as a guard, so that should be taken into account. Should we be running relays over IPv6 tunnels? Tim [0]: We're working on it in https://trac.torproject.org/projects/tor/ticket/17840 <https://trac.torproject.org/projects/tor/ticket/17840> Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Revised Opt-In Trial: Fallback Directory Mirrors
> On 13 Jan 2016, at 02:56, Aeris <aeris+...@imirhil.fr> wrote: > >> Here's the latest list of fallback directory candidates: >> https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di >> rs.inc.20160112 > > ... > (I already opt-in for it inclusion on december, with my others nodes > (kitten[1-4])). Hi Aeris, kitten3 doesn't have a DirPort configured. Relays need a DirPort to be a fallback directory mirror. Let me know if you are able to configure a DirPort for it. Also let me know if you want to opt-in or opt-out other relays in that family. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 18 Dec 2015, at 04:49, Pascal Terjan <pter...@gmail.com> wrote: > On 17 December 2015 at 14:07, Nick Mathewson <ni...@torproject.org > <mailto:ni...@torproject.org>> wrote: > For the initial fallback release, we will only add your relay if you > opt in. Please reply on the tor-relays mailing list, if you are able. > (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be > managed using lists in the publicly available tor git repository.) > > Just to be sure, you are not yet interested in opt-outs? > I have a relay quite high in the list (chopin, > 953DB709F2A2DECC8D7560661F934E64411444F7) but it is running at home and I am > likely to move in less than 2 years so it should be opted out when things > will no longer be option. Hi Pascal, Thanks for the opt-out, it helps us know which relays to avoid in future. I noticed there are some other relays in that family, should they be opt-in or opt-out? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 18 Dec 2015, at 09:23, Tim Wilson-Brown - teor <teor2...@gmail.com> wrote: >> On 18 Dec 2015, at 06:31, ]V[ <mart...@beekhuis.org >> <mailto:mart...@beekhuis.org>> wrote: >> Able! >> > > ... > Thanks, can you let me/us know the names your relay(s)? > (I need to know the names to add them to the opt-in list.) Hi Martjin, I could not find any relays with your email address in their contact info. If you want to opt-in your relays as fallback directory mirrors, can you send me their names or fingerprints? Thanks Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 19 Dec 2015, at 05:53, Felix <zwie...@quantentunnel.de> wrote: > ... > I'm happy to bring in the relay Doedel22 > '8FA37B93397015B2BC5A525C908485260BE9F422'. Hi Felix, There are some other relays in that family, did you want to opt-in or opt-out for them? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 12 Jan 2016, at 23:30, Joost Rijneveld <jo...@joostrijneveld.nl> wrote: > > Hi all, > >> On 17 Dec 2015, at 15:07, Nick Mathewson wrote: >> If your relay is on this list, and you expect it to be on the same IP >> address(es) and port for at least 2 years, please consider opting-in >> for this trial. > > I realise it's been a while since the last post in this thread, but > I'd like to opt-in. That's OK, we're still taking opt-ins. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Revised Opt-In Trial: Fallback Directory Mirrors
> On 12 Jan 2016, at 16:09, starlight.201...@binnacle.cx wrote: > > Hmm, don't see the script in this Git repository, > most recently updated files are from a month ago. Yes, my branch has some bug fixes that are awaiting review before they get merged into tor master. > > > At 15:35 1/12/2016 +1100, you wrote: >> This list was generated a few minutes ago from >> scripts/maint/updateFallbackDirs.py in my branch fallback-17887-17888-18035 >> on [2]. (This branch has some bug fixes compared to what's in master.) >> >> [2]: <https://github.com/teor2345/tor.git>https://github.com/teor2345/tor.git > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Revised Opt-In Trial: Fallback Directory Mirrors
> At 19:20 1/12/2016 +0100, Aeris wrote: >>> Are you *absoultely* certain that the config >>> was not fiddled with at the time of this event? >> >> After grepping some logs, seems 13/12 was the day of a Tor >> upgrade : >> >> 2015-12-13 10:47:31 upgrade tor:amd64 0.2.7.5-1~d80.jessie+1 >> 0.2.7.6-1~d80.jessie+1 >> 2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1 >> >> Timing is good compare to the 10:48:46 of the consensus ! >> >> But I donât remember a config change after that, >> perhaps only on /usr/share/tor/tor-service-defaults-torrc >> or on a default config param change ? >> >> And perhaps the Tor reboot cause the DirPort to >> be temporarily disabled (seems not human, only >> 2s duration) ? I wonder if the DirPort self-test finished ~62 seconds after the ORPort self-test? (Or, strictly, after the first descriptor was submitted?) That would explain the behaviour we're seeing here. (And it shouldn't be grounds for exclusion as a fallback directory, let me see what I can do.) Logged in trac as #18050. https://trac.torproject.org/projects/tor/ticket/18050 <https://trac.torproject.org/projects/tor/ticket/18050> Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Revised Opt-In Trial: Fallback Directory Mirrors
> On 13 Jan 2016, at 10:33, Tim Wilson-Brown - teor <teor2...@gmail.com> wrote: > > >> At 19:20 1/12/2016 +0100, Aeris wrote: >>>> Are you *absoultely* certain that the config >>>> was not fiddled with at the time of this event? >>> >>> After grepping some logs, seems 13/12 was the day of a Tor >>> upgrade : >>> >>> 2015-12-13 10:47:31 upgrade tor:amd64 0.2.7.5-1~d80.jessie+1 >>> 0.2.7.6-1~d80.jessie+1 >>> 2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1 >>> >>> Timing is good compare to the 10:48:46 of the consensus ! >>> >>> But I donât remember a config change after that, >>> perhaps only on /usr/share/tor/tor-service-defaults-torrc >>> or on a default config param change ? >>> >>> And perhaps the Tor reboot cause the DirPort to >>> be temporarily disabled (seems not human, only >>> 2s duration) ? > > I wonder if the DirPort self-test finished ~62 seconds after the ORPort > self-test? > (Or, strictly, after the first descriptor was submitted?) > > That would explain the behaviour we're seeing here. > (And it shouldn't be grounds for exclusion as a fallback directory, let me > see what I can do.) The fallback directory update script uses the OnionOO field last_changed_address_or_port, which is implemented correctly: the relays in question did stop announcing their DirPort within the last 120 days. In the fallback directories script, there doesn't seem to be any way to work around the special case where relays stop announcing their DirPort for a single descriptor/consensus because they have been restarted, and their DirPort self-test has not finished yet. So I don't know if there's any way to fix this, apart from fixing the underlying issue with the relay code, and waiting 120 days for the previous upgrades to be old enough that they don't matter any more. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Revised Opt-In Trial: Fallback Directory Mirrors
Hi all, Nick sent an email in December[0] asking relay operators to opt-in as a fallback directory mirror. This will help tor clients reach the tor network, and reduce the load on directory authorities.[1] We will keep the opt-ins and opt-outs submitted so far - no need to opt-in or opt-out again! If you run an under-utilised exit, we encourage you to opt-in as a fallback directory. We've also fixed a major bug that excluded some relays from the list. (Thanks starlight!) Here's the latest list of fallback directory candidates: https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_dirs.inc.20160112 <https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_dirs.inc.20160112> This list was generated a few minutes ago from scripts/maint/updateFallbackDirs.py in my branch fallback-17887-17888-18035 on [2]. (This branch has some bug fixes compared to what's in master.) Tim [0]: https://lists.torproject.org/pipermail/tor-relays/2015-December/008361.html <https://lists.torproject.org/pipermail/tor-relays/2015-December/008361.html> [1]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors <https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors> [2]: https://github.com/teor2345/tor.git <https://github.com/teor2345/tor.git> Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 12 Jan 2016, at 12:11, Tim Wilson-Brown - teor <teor2...@gmail.com> wrote: > > >> On 12 Jan 2016, at 10:14, starlight.201...@binnacle.cx >> <mailto:starlight.201...@binnacle.cx> wrote: >> >> Found a serious bug in the >> >> updateFallbackDirs.py >> >> script used to generate the fallback relay >> candidate list. The OnionOO retrieval used >> to pull flag history returns the entire >> history of each relay rather than the >> 120 days requested. >> >> This results in 145 relays left >> off the list as too-old history is >> averaged into the percentages. > > Thanks, logged as #18035 > https://trac.torproject.org/projects/tor/ticket/18035 > <https://trac.torproject.org/projects/tor/ticket/18035> I've reviewed this patch and it looks good. I updated it for the latest version of the script in the tor git repository, as it was based on an old version. I've also logged the more general issue with OnionOO and date ranges as #18036. https://trac.torproject.org/projects/tor/ticket/18036 <https://trac.torproject.org/projects/tor/ticket/18036> Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 12 Jan 2016, at 10:14, starlight.201...@binnacle.cx wrote: > > Found a serious bug in the > > updateFallbackDirs.py > > script used to generate the fallback relay > candidate list. The OnionOO retrieval used > to pull flag history returns the entire > history of each relay rather than the > 120 days requested. > > This results in 145 relays left > off the list as too-old history is > averaged into the percentages. Thanks, logged as #18035 https://trac.torproject.org/projects/tor/ticket/18035 <https://trac.torproject.org/projects/tor/ticket/18035> Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why is Tor trying to check the wrong ORPort/DirPort addresses?
> On 9 Jan 2016, at 01:22, David Tomic <da...@tomic.com.au> wrote: > > I got a little bit excited a few minutes ago when I discovered > https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create.8.txt > > <https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create.8.txt> > > However, that doesn't appear to have made any difference either. For some > reason the reachability tests are still insisting on trying to connect to > .102. Tor should only fall back to using an interface address when it fails to parse the Address torrc option. So you may have found a bug in the tor function resolve_my_address(). (Tor should also probably pay attention to the address in the ORPort line when testing reachability, but that's a separate issue.) Can you please choose a tor instance with this issue, and provide: * The exact Address, ORPort and DirPort lines (or the entire torrc, if you're able) * The debug-level log output for the first and second calls to resolve_my_address() * there will be a lot of output here, and it can reveal sensitive info - don't leave debug logging on all the time! Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why is Tor trying to check the wrong ORPort/DirPort addresses?
> On 9 Jan 2016, at 00:39, Roman Mamedov <r...@romanrm.net> wrote: > > On Fri, 8 Jan 2016 23:39:59 +1100 > David Tomic <da...@tomic.com.au> wrote: > >> The problem appears when Tor tries to verify that my ORPort/DirPort are >> reachable, because for some reason it's trying to check the wrong IP >> address? > > Did you try setting OutboundBindAddress? This will help other relays identify connections from your relay as canonical, but it won't affect the address your relay uses for itself. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Debugging my small relay
> On 8 Jan 2016, at 21:17, Markus Hitter <m...@jump-ing.de> wrote: > > Am 08.01.2016 um 07:33 schrieb Tim Wilson-Brown - teor: >> What matters is the bandwidth it can contribute to censored users. >> The advertised bandwidth is 100KB/s, which is somewhat low for a bridge. >> As far as I recall, 250KB/s is considered a good minimum for a bridge. > > Yes, I'm aware of this "recommended minimum". But it's not me limiting > bandwidth artifically, it's what the current hardware delivers. These > 100 kB/s come for free, raising them would come with a price tag (xx > Euros per month). > > So the question is wether to take these 100 kB or wether to stop the > relay entirely. I could well imagine such small contributions are more > than nothing. I could also imagine to see thousands of such small > relays, because they cost nothing and run barely noticeable to the > non-Tor, everyday traffic. "Help freedom of speech at no cost" sounds > really good, many others could chime in, if approached by some > marketing. If there were thousands of them, their bandwidth would add > up, right? > > Another consideration is that it doesn't matter too much wether the > bandwidth is actually used. I _could_ be used, raising the obfuscation > the Tor network relies so heavily on. > > What do you think? There's a point at which distributing the information for a new relay (in consensus documents and microdescriptors) outweighs the bandwidth contributed by that relay. I also wonder how much diversity Tor gains from small relays. I'm not sure how this works out, it may depend on your threat model. (Or the client's threat model.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why is Tor trying to check the wrong ORPort/DirPort addresses?
> On 9 Jan 2016, at 00:03, David Tomic <da...@tomic.com.au> wrote: > > I have already done that, so that doesn't appear to be the problem. I see > exactly the same problem even when I'm only starting up a single instance. > Tor binds everything to the correct ip:port, but the reachability test always > tries to connect to the .102 ip address. What IP addresses does Tor mention in its log as it is starting up? > Is it possibly something to do with the way that my network interfaces are > configured? FWIW I haven't actually touched anything there, it's still > exactly how it was originally provided to me by the host: It appears that the Address option hasn't been applied, and Tor is still guessing based on the IP address of the last interface. Please send a HUP to your tor instances after changing their configs, or restart them entirely. As a separate issue, Tor really should use the addresses from the ORPort or DirPort to check reachability (what if they're different?), and fall back to Address if there isn't an explicit address set for either port. This might mean setting Address based on the ORPort address. (But what if they conflict?) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Debugging my small relay
> On 8 Jan 2016, at 16:26, Green Dream <greendream...@gmail.com> wrote: > > Is there really a reason to continue running this relay, even as a bridge? It > has a consensus weight of 9. Before the upgrade and subsequent fingerprint > reset, it was only at cw 16. The mean middle probability fraction was > 0.000103%. The mean on the read/write was less than half a kilobyte per > second. It's not really being used. A bridge exists to allow censored users access to the Tor network. So its consensus weight and use by the Tor network aren't really relevant. What matters is the bandwidth it can contribute to censored users. The advertised bandwidth is 100KB/s, which is somewhat low for a bridge. As far as I recall, 250KB/s is considered a good minimum for a bridge. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] What are the exact requirements for HSDir flag?
> On 1 Jan 2016, at 13:21, Dimitar Milkov <m...@programings.eu> wrote: > > Hello, and Happy New Year! > > I have a question regarding the HSDir flag. > > According to dir-spec.txt : > > "A router is a v2 hidden service directory if it stores and serves v2 hidden > service descriptors, has the Stable and Fast flag, and the authority believes > that it's been up for at least 96 hours (or the current value of > MinUptimeHidServDirectoryV2)." > > However, if you browse the consensuses, you will find a lot of relays that > meet the requirements above, but doesn't have HSDir. > You will also notice that almost every relay with HSDir is also a > conventional v2 directory mirror (e.g. with active DirPort). > > Is there any non-documented requirement, like minimum bandwidth or something? The "Fast" flag imposes a minimum bandwidth requirement. The "Stable" flag imposes an uptime requirement. Each authority does its own relay reachability testing, and so their views of the network may differ, as may their values for some of the other parameters used to vote for HSDirs. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] problem with new and old exit relays
> On 31 Dec 2015, at 13:58, Larry Brandt <lbra...@cni.net> wrote: > > Recently I have been receiving warnings on notices.log shown below. Today I > started a new exit relay and immediately received a similar message. Is this > familiar to anyone? What's my problem? > > Dec 31 03:26:35.000 [warn] Malformed IP "???" in address pattern; rejecting. > Dec 31 03:26:35.000 [warn] Couldn't parse line "[???]:*". Dropping > Dec 31 03:26:35.000 [warn] Malformed policy 'reject [???]:*'. Discarding > entire policy list. > Dec 31 03:26:35.000 [warn] append_exit_policy_string(): Bug: Unable to > parse internally generated policy reject [???]:* (on Tor 0.2.7.6 ) Hi Larry, This is a harmless warning that happens when tor skips an address policy created from an invalid address. The rest of the internal address policy creation works fine - tor is doing exactly what it's supposed to, it's just noisy about it. It's fixed in master (and the fix will be released in 0.2.8), but we decided not to do a backport to 0.2.7 just to fix an extra warning. https://trac.torproject.org/projects/tor/ticket/17762 <https://trac.torproject.org/projects/tor/ticket/17762> Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Sustained large spike in outbound traffic - what might be going on?
> On 30 Dec 2015, at 08:19, Toralf Förster <toralf.foers...@gmx.de> wrote: > > Signed PGP part > On 12/29/2015 12:53 PM, Tim Wilson-Brown - teor wrote: > > > > I don't know of any other attack or request that amplifies outbound > > traffic via tor or otherwise, but there may be some. > > I did experienced too a gap of incoming versus outgoing of about 30% and more > few times in the past at an exit relay, having an advertised bandwidth of 8 > MB/sec. That gap persists over a day or so and then vanished. A day is the HSDir rotation period, perhaps there is a popular hidden service which serves 8-30MB/s worth of descriptors. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Sustained large spike in outbound traffic - what might be going on?
> On 29 Dec 2015, at 22:44, Julien ROBIN <julien.robi...@free.fr> wrote: > > Hi, > > In fact, this is strange because Upload means that the server is receiving > something to send, idem for Downloads : upload and download should be the > same if the Tor Process is used as server only (relay or exit). Yes, you're right, my original email was mistaken - any uploads or downloads go in via tor and out to the Internet (or vice versa). The only things I can think of that could cause an increase in outbound traffic are: * cell padding for many small internet server responses (up to 512x for a 1-byte response), * becoming a hidden service directory for a popular hidden service, * having a lot of clients download directory documents at once (this shouldn't happen, client directory downloads are randomised), * having clients make lots of DNS requests via your exit (again, this shouldn't happen, DNS requests are limited size). I don't know of any other attack or request that amplifies outbound traffic via tor or otherwise, but there may be some. Perhaps you could see what kind of traffic you are sending if it happens again. (It's hard to help without more information.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Sustained large spike in outbound traffic - what might be going on?
> On 23 Dec 2015, at 19:32, David Tomic <da...@tomic.com.au> wrote: > > Hello everyone, > > I noticed something a little bit "odd" on one of my exit relays recently, and > I just wanted to ask whether anybody might be able to account for what was > actually happening, and whether it's likely to warrant any further > investigation? > > TLDR; I noticed a fairly significant spike - in excess of 30MB/s (yes, > megabytes) - of outbound traffic compared to inbound. > > http://s2.postimg.org/cvfzqvrsp/graph.png > <http://s2.postimg.org/cvfzqvrsp/graph.png> > > It persisted steadily for just over an hour, until I noticed what was going > on and restarted Tor (not the whole server, only Tor), at which point my > traffic appeared to return to normal again. > > I have this relay running a a dedicated machine, with multiple physical NICs, > and the ONLY thing which should be touching this NIC is my Tor traffic. > > Thoughts? Exit relays can end up with large traffic disparities for two reasons: * small internet server requests can yield large internet server responses, or vice versa * Tor cells are 512 bytes, if a small request or small response is embedded in a cell, the overhead can be quite large This could happen because someone is uploading or downloading a large file. But 30MB/s would probably require more than one client at the same time. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] IPv6 Only Exit Node
> On 21 Dec 2015, at 03:36, Toralf Förster <toralf.foers...@gmx.de> wrote: > > Signed PGP part > On 12/15/2015 07:25 PM, Tim Wilson-Brown - teor wrote: > > > > This is wise. Tor will block your own IPv6 address, but it doesn't > > know about your subnet: > > > >> ExitPolicy reject6 [2A02:168:4A06::]/42:* # Block my subnet > > > > Just clarify it for me : the ":*" isn't needed here, or ? It isn't needed, Tor assumes that any address without a port rejects or accepts all ports on that address. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 20 Dec 2015, at 02:55, NOC <noc@babylon.network> wrote: > > The initial message states that the relays should be non-exit replays. > All these relays are exit relays with enough resources to spare so I > would love to see them added. > ... > > -- > Tim Semeijn Hi Tim, Thanks for opting-in these relays. I didn't realise that there are under-utilised exit relays in the Tor network. (I was the one who added "not an exit relay" to the fallback directory criteria.) We'll review the criteria before we select the final list. Please feel free to opt-in other under-utilised exit relays. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 20 Dec 2015, at 23:42, NOC <noc@babylon.network> wrote: > > Signed PGP part > Good to hear the criteria will be reviewed. As far as I am aware there > are under-utilised resources on these two exit relays so that is why I > am opt-ing in these relays. > > If there is any more information on the expected resources for the > fallback directory mirrors that will be used I am all ears ;) With 100 fallback directory mirrors, up to an extra 50 GB per fallback per month. (This is my estimate of the maximum extra load, averaged across 100 fallbacks. But client consensus downloads will actually be distributed by the fallback's consensus weight, so larger relays may use more.) I suspect most fallback directories won't notice the extra load. Here are the details: At the moment, new Tor clients contact a directory authority to download their initial consensus. After we release the fallback directory feature, new clients will contact a fallback directory mirror to download their initial consensus. (Bridges will also contact fallback directory mirrors, as they are designed to behave like clients. Most relays will contact an authority.) Clients will choose a fallback using at random, weighted based on their consensus weight. If a client is on a slow, unreliable, or censored connection, they may contact several mirrors before they get a successful connection. (However, regardless of the number of connection attempts, the consensus download only happens once.) After the initial consensus download, clients will choose from the full set of directory mirrors in the consensus. We expect that most clients will already have a consensus, it will only be the new installs that use a fallback directory mirror. So if you take the download counts for the new version of Tor Browser, multiply by about 1.5MB (the size of a microdesc consensus), then distribute that by consensus weight over the fallback directory mirrors, that's the extra load we expect to place on each fallback directory mirror. Alternately, if you take the bandwidth that a directory authority uses to serve consensuses to clients, and divide by 11, then that's how much we expect a fallback directory mirror to handle on average. (There are 9 authorities, and we hope to have 100 fallback directory mirrors.) Unfortunately, I don't know the number of Tor Browser downloads. And while I can see that the authorities use 110 - 230 KB/s of bandwidth[0], I don't know how much of that is client consensuses. If we assume that the entire authority bandwidth is used for client consensuses, then I would expect that a fallback directory mirror would use: 110 - 230 / 11 = 10 - 21 KB/s additional bandwidth, or an extra 26 - 54 GB per month on average, distributed by consensus weight. It's worth noting that the entire Tor network already uses 1Gbit/s to serve directory documents[1], and first-time downloads for new clients are only a fraction of that. So I suspect most fallback directory mirrors won't notice the extra load. If you're interested in some further background, the original proposal is at [2]. Tim [0]: https://globe.torproject.org/ <https://globe.torproject.org/> [1]: https://metrics.torproject.org/dirbytes.html <https://metrics.torproject.org/dirbytes.html> [2]: https://gitweb.torproject.org/torspec.git/tree/proposals/210-faster-headless-consensus-bootstrap.txt <https://gitweb.torproject.org/torspec.git/tree/proposals/210-faster-headless-consensus-bootstrap.txt> > > > On 12/20/2015 01:31 PM, Tim Wilson-Brown - teor wrote: > > > >> On 20 Dec 2015, at 02:55, NOC <noc@babylon.network > >> <mailto:noc@babylon.network>> wrote: The initial message states > >> that the relays should be non-exit replays. All these relays are > >> exit relays with enough resources to spare so I would love to see > >> them added. ... > >> > >> -- Tim Semeijn > >> > > > > Hi Tim, > > > > Thanks for opting-in these relays. > > > > I didn't realise that there are under-utilised exit relays in the > > Tor network. (I was the one who added "not an exit relay" to the > > fallback directory criteria.) We'll review the criteria before we > > select the final list. > > > > Please feel free to opt-in other under-utilised exit relays. > > > > Tim > > > > Tim Wilson-Brown (teor) > > > > teor2345 at gmail dot com PGP 968F094B > > > > teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F > > B5A9D14F > > > > > > > > ___ tor-relays mailing > > list tor-relays@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > -- > Tim Semeijn > Babyl
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 21 Dec 2015, at 01:55, s7r <s...@sky-ip.org> wrote: > > Signed PGP part > Hi, > > The estimated extra load looks good, it shouldn't be a problem. > > Are we entirely sure we want to hardcode a static weight for each > fallback directory relay? I know we require it to be stable enough but > sometimes the weight assigned to a relay is outside the control of the > operator (more relays are added to the Tor network so consensus weight > distribution changes, the relay gets DoS-ed and becomes slow at the > next measurement). If there are 100 fallback directories, and clients try several (see below), it doesn't matter if a few are down or busy or are being DoSed. And it's the relative weights among the set of fallback directories that are used by clients to select a fallback directory: if more relays are added to the Tor network, the relative weights of the fallback directories stay the same. (And we pick up the new weights in the next release.) > > > If all the relays eligible for being added as fallback directory > relays are required to have a big enough weight, this means the > estimated extra load shouldn't be a problem for neither of them. In > this case how bad will it be if we do not hardcode a static weight and > give equal chances to all fallback directory relays to be selected by > new clients? That's a possibility, it's what we currently do for authorities - clients select an authority at random, without considering their consensus weights. I like the simplicity of giving all the fallback directories the same weight, but I think it's wise to add any extra load in proportion to the existing load on the relay. And I don't know whether equal weights is a viable option for fallback directories - it will depend on their consensus weights being similar enough. (The code currently uses weights, but we could set them all to the same weight if we wanted to.) The December 2015 list of candidate fallback directories[0] has relative weights from 2.3% to 0.008%. While we'd likely exclude some relays at the lower end, a relay that helps 1 in 1000 clients connect to the Tor network is still performing a useful role. And there's several tradeoffs we will consider when creating the list. There's a tradeoff between including small relays, and the cost of increasing the size of the tor binary with each fallback in the list. There's also the risk that including small relays will lead to them not being able to cope with the extra load. At the higher end, there's a tradeoff between weighting according to consensus weight, and letting a fallback directory see too many clients join the network. (Authorities see approximately 11% of clients that join the Tor network, so we would set the maximum fallback weight lower than that.) The script we use to select fallback directories has parameters that allow us to control these sorts of tradeoffs, you can see many of them listed in a comment at the top of the file[0]. [0]: https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_dirs.inc > > As you said on irc, a client will try (maybe 3) fallback directories > before giving up and going to the directory authorities. Currently, a client will try 3 fallback directories before trying an authority, another fallback directory, another authority, then giving up for an hour. (This aims to provide ~99.9% bootstrap success within 20 seconds, without increasing the load on the authorities - even if a few authorities and many fallbacks are down. We can fine-tune it before release if we need to.) Tim > > > > On 12/20/2015 3:37 PM, Tim Wilson-Brown - teor wrote: > > > > With 100 fallback directory mirrors, up to an extra 50 GB per > > fallback per month. (This is my estimate of the maximum extra load, > > averaged across 100 fallbacks. But client consensus downloads will > > actually be distributed by the fallback's consensus weight, so > > larger relays may use more.) I suspect most fallback directories > > won't notice the extra load. > > > > Here are the details: > > > > At the moment, new Tor clients contact a directory authority to > > download their initial consensus. > > > > After we release the fallback directory feature, new clients will > > contact a fallback directory mirror to download their initial > > consensus. (Bridges will also contact fallback directory mirrors, > > as they are designed to behave like clients. Most relays will > > contact an authority.) Clients will choose a fallback using at > > random, weighted based on their consensus weight. > > > > If a client is on a slow, unreliable, or censored connection, they > > may contact several mirrors before they get a successful > > connection. (However, regardless of the
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 18 Dec 2015, at 06:31, ]V[ <mart...@beekhuis.org> wrote: > > Able! > (Hi, I'm teor, I'll be pulling together the opt-ins and opt-outs for Nick.) Thanks, can you let me/us know the names your relay(s)? (I need to know the names to add them to the opt-in list.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> On 18 Dec 2015, at 04:49, Pascal Terjan <pter...@gmail.com> wrote: > > > > On 17 December 2015 at 14:07, Nick Mathewson <ni...@torproject.org > <mailto:ni...@torproject.org>> wrote: > For the initial fallback release, we will only add your relay if you > opt in. Please reply on the tor-relays mailing list, if you are able. > (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be > managed using lists in the publicly available tor git repository.) > > Just to be sure, you are not yet interested in opt-outs? > I have a relay quite high in the list (chopin, > 953DB709F2A2DECC8D7560661F934E64411444F7) but it is running at home and I am > likely to move in less than 2 years so it should be opted out when things > will no longer be option. (Hi, I'm teor, I'll be pulling together the opt-ins and opt-outs for Nick.) I'll keep a list of opt-outs. They will be useful if we move to automatically including relays in future releases. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] IPv6 Only Exit Node
> On 16 Dec 2015, at 04:23, Hans Wurscht <t...@x2a.ch> wrote: > > Hi > > I would like to operate an IPv6 only exit node. I.e. it's fine if tor relays > through IPv4, but I want exiting traffic only through IPv6 (because I don't > want my (only) IPv4 to be blocked, abused and such). You won't get the Exit flag unless you exit to at least one IPv4 /8, on at least: * port 80 & 443, or * port 80 & 6667, or * port 443 & 6667. It's a documented issue that a relay can still get the Exit flag by exiting to an unused IPv4 /8 that's not in Tor's list of private addresses. > The way I thought this would work is with the ExitPolicy set as below. But > atlas says my IPv6 Exit Policy Summary would be "ExitPolicy reject *:*". I don't know if Atlas does this because your relay doesn't have the Exit flag, or because your relay's policy rejects everything, or because your relay's policy doesn't allow IPv4. > Now I'm wondering if my ExitPolicy is wrong defined or if that's a bug of > some kind. What is the exit policy in your relay's descriptor? > I'm running Tor v0.2.7.5 (git-6184c873e90d93b2) on Linux with Libevent > 2.0.21-stable, OpenSSL 1.0.1k and Zlib 1.2.8. These rules look like they should work as you describe. (Tor 0.2.7 was fixed to make accept6/reject6 only produce IPv6 rules.) Let me do some testing to see if you've uncovered a bug. > # No IPv4 exit, no exit to my own subnet, no exit to private network, no exit > to link local This is wise. Tor will block your own IPv6 address, but it doesn't know about your subnet: > ExitPolicy reject6 [2A02:168:4A06::]/42:* # Block my subnet Tor blocks private addresses by default, so these lines are redundant, but harmless: > ExitPolicy reject6 [FC00::]/7:*# Block private IPv6 > ExitPolicy reject6 [FE80::]/10:* # Block link-local IPv6 Tor doesn't block 6to4 addresses by default, so this is useful: > ExitPolicy reject6 [2002::]/16:* # Block 6to4 addresses > ... This should make sure most IPv6 ports are accepted, because it comes before the reject rules. You could try: "ExitPolicy accept6 *6:*", but it should have exactly the same outcome. > ExitPolicy accept6 *:* # All else This actually blocks private IPv4 and IPv6, and it's redundant because Tor blocks private addresses by default: > ExitPolicy reject private:*# Block private IPv4 This actually blocks IPv4 and IPv6: > ExitPolicy reject *:* # Block all IPv4 > > ## If set, and we are an exit node, allow client to use us for IPv6 traffic > IPv6Exit 1 Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unused Tor exit nodes capacity
> On 16 Dec 2015, at 09:07, Dirk Eschbach <tor-relay.d...@o.banes.ch> wrote:
>
> ...
>
> Finally a set logfiles to debug and started greping for err:
>
> Dec 15 22:55:50.000 [info] {EDGE} connection_edge_process_relay_cell():
> 617: end cell (misc error) for stream 7289. Removing stream.
> Dec 15 22:55:50.000 [debug] {NET} tor_tls_read(): read returned r=-1, err=-2
> …
err=-2 is SSL_ERROR_WANT_READ. It happens when OpenSSL is waiting for more data
from the network.
It could be normal, so it's hard to tell if you're experiencing too many of
these errors.
Are there delays reading from network sockets, or packet loss, or something
similar?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Handling abuse request about stopforumspam.com
> On 15 Dec 2015, at 18:24, Eran Sandler <e...@sandler.co.il> wrote: > > Hi guys, > > One of my tor server seems to be getting a lot of abuse reports from the ISP > from stopforumspam.com <http://stopforumspam.com/>. > > http://www.stopforumspam.com/ipcheck/212.47.246.21 > <http://www.stopforumspam.com/ipcheck/212.47.246.21> > > Any idea how to reduce those to a minimum in a reasonable way? Ideally, the forums would work out some way to block connections based on behaviour, rather than source IP. But in the absence of such sensible measures, there are some things you can do. Can you block particular IP ranges / ports in your exit policy to avoid the complaints? For example, if the complaint is from a destination 1.2.3.4:80, add a rule at the *top* of your exit policy saying: ExitPolicy reject 1.2.3.4:80 You can add IPv6 addresses, port ranges and address masks too: ExitPolicy reject 1.2.3.4/24:443-445 ExitPolicy reject [2002::abcd]:8080 Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] uptime "algorithm"
> On 15 Dec 2015, at 13:12, Nima Fatemi <n...@riseup.net> wrote: > > Roger Dingledine: >> We should somehow teach everybody that losing their flags for a few days >> is totally fine and normal, and even something to be proud of because >> you took a useful step at keeping your Tor relay safe and secure > > Maybe we should introduce a new flag for the relays that are running the > cutting edge version of Tor? There's a startup warning for this: it says your relay version is "too new". > And another one for long-time relays. say, if a relay has been in the > consensus, it would get an special flag of some sort… At some point, we'd like to make long-term relays fallback directory mirrors. That's not a flag, but it is a special kind of status. Also, isn't this the kind of thing that tor-roster does? I think these kinds of features would be better there, rather than cluttering up the consensus. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Webiron at it again...
> On 16 Dec 2015, at 01:43, Schokomilch NOC <n...@schokomil.ch> wrote: > > Monday we received their usual spam about our exit-node sending spam, and of > course instead of implementing the TorDNSEL on their sites, they rather want > us to block a whole /24 range. > > Anyhow, one line caught our eyes: > > "Tor: Please note as the abuse from Tor has gotten out of hand, we do not > give free passes to abuse coming from Tor exits. See the leader board linked > below for more details on the issue." > > They also include a link to some fancy unresolved abuse ranking[1]. > ... > I think that having a tiny bit less than 1/4 of all abuse reports originating > from Tor is a pretty great value and not "out of hand" at all. You also have to scroll down their list for a long time before finding any "onion with sunglasses" symbols. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay isn't getting HSDir flags
> On 14 Dec 2015, at 09:45, Random Tor Node Operator <c...@fu110.de> wrote: > > Hi, > > you didn't get the V2Dir flag with AccountingMax set on... I had to have the > same experience with that. You will only get the V2Dir flag with AccountingMax on if your relay is sure it will never hit its bandwidth cap. This will only happen after the first full period, if at all. Tim > > > Random Tor Node Operator > > hi > Am 13.12.2015 um 23:32 schrieb Lucas Werkmeister: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> Hi all! >> >> For some reason, my relay[1] isn't getting the HSDir and V2Dir flags. >> This is the full config, sans comments (sed '/^#\|^$/d' /etc/tor/torrc): >> >> SocksPort 0 >> DataDirectory /var/lib/tor >> ORPort 9001 >> Address 78.46.139.153 >> Nickname BotIfMuvasfo >> AccountingMax 7900 GB >> AccountingStart month 15 00:00 >> ContactInfo Lucas Werkmeister "6B89 5B8B 11A4 75B1 EC93 1698 FC46 2872 >> 72AE 323F" <m...@lucaswerkmeister.de <mailto:m...@lucaswerkmeister.de>> >> DirPort 9030 # what port to advertise for directory connections >> ExitPolicy reject *:* # no exits allowed >> >> I reloaded the config several times since I uncommented the DirPort >> line, and even restarted the relay earlier today just in case enabling >> DirPort wasn't supported without restart. No luck - both Globe[1] and >> Atlas[2] don't show the HSDir or V2Dir flags. >> >> A few months ago, I had the relay running on a different server. I had >> enabled the DirPort there for a while, but eventually was forced to >> disable it since the server couldn't handle the load. But back then, the >> relay got the flags without any problem. Since I moved to a new server >> (copying over the torrc and data directories), this doesn't seem to be >> working anymore. (I am now on Debian 8, tor version 0.2.5.12; the old >> server was on Debian 7, tor version 0.2.4.27.) >> >> Any ideas on what the problem here could be? >> >> Thanks a lot, >> Lucas >> >> [1]: >> https://globe.torproject.org/#/relay/C527AD7D47E9DEC163537A444F4F790433CD67F7 >> [2]: >> https://atlas.torproject.org/#details/C527AD7D47E9DEC163537A444F4F790433CD67F7 >> >> <https://atlas.torproject.org/#details/C527AD7D47E9DEC163537A444F4F790433CD67F7> >> -BEGIN PGP SIGNATURE- >> >> iQIcBAEBCgAGBQJWbfIFAAoJEPxGKHJyrjI/B3AP/18uMBavSAQeHyYDr5D89bBQ >> JlTmDwWdolNc7SwNeaUTB8w+KYEatyVXJh7uAF4jrjKIS9eplMMU+1rcLS6C2tO4 >> 4hvu9cYGwXepkuh742ikPIXivj7X08BqP+c38GYyXIC/mxdUJ44AZwGa3z4guWEl >> 6Qb9FtdxJ2NBMdtHjvmyFTUN2qYK0k6qYzoHygCyrf/OyoHjynkMRPKwaoHEgZhG >> yBIcf8AlOnKUf5+cVwkUZeurZ0l0KPl0hawUNDELciOMkGchMDyb6ui6u7LbCDVL >> gRiBToU6RJIiPo6vKw7UbAZeNeodNeXalmLMTL7vuKzhJjYgDae1bTJEQvMWdz6i >> nNxssOLHhBkTwdJosj1Kaw4a+opcqA8bPJY0KeAaZUnvAGro/lOwb0Tc7oDkbg2b >> Xb5IuQfWpZzpOuGldfisdqXRL1rySsnCaGSsFT9ulrkXaz42UDQE8pyxy8ErqL4j >> byhGiQF0F04sWldQPy3AjfZEImtBROx9PetESMLLyD6UYWffEGr6JLtIoolPEA0x >> OjMOGuyq91gJEZ2xIdlN+kJaylmnu/8kGKD6vAJwBxX8wVHWIyD5KbQOyL2RjCT8 >> gtiSFdIj8mZmvKUR5svWrgxfGoVGc5a76CUyLF+7Jd+d3DPPOlGXX+dJ/WErjgjH >> JbmjWbI1OIBai6gKvlSE >> =BmwK >> -END PGP SIGNATURE- >> >> >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays> > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays> Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] expected IPv6 traffic for an exit relay
> On 13 Dec 2015, at 02:52, Toralf Förster <toralf.foers...@gmx.de> wrote: > > Signed PGP part > I opened my exit for IPv6 after Moritz encouraged us to do so here at this > list. > > I do observe a traffic of 1-2 GB. for IPv6, IPv4 is always abound 300 GB/day. > The exit is configure for 8 MB/sec throughgput (==20 TB/month). > I do wonder, what are expected values for IPv6. > > Furthermore between 11th of August and 25th of September I observed a traffic > of about 30-40 GB per day for IPv6 - but why only in this time frame ? Tor Browser 5.0.4 has its SOCKSPort configured with "IPv6Traffic PreferIPv6". This means that if your DNS resolver returns IPv6 records, Tor Browser and your Exit should default to using IPv6 to websites that have both an IPv4 and IPv6 address. Is your DNS resolver correctly returning records along with A records for all sites that have them? (If it's only returning records for a few sites, or for IPv6-only sites, that could be your problem.) As far as I know, nothing changed in Tor Browser that could cause a dramatic IPv6 traffic drop-off. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Crash and obfs error
> On 10 Dec 2015, at 15:52, Yawning Angel <yawn...@schwanenlied.me> wrote: > > On Thu, 10 Dec 2015 01:26:41 + > Geoff Down <geoffd...@fastmail.net> wrote: > > ... > >> It's quite annoying that Tor doesn't remember its auto-picked port, >> and I have to change the port-forwarding rule every time. > > This should get persisted in the state file. It seems a few people are encountering this issue. https://trac.torproject.org/projects/tor/ticket/3511 <https://trac.torproject.org/projects/tor/ticket/3511> (We'd love a patch to fix this!) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge Accounting Period Resets Stats
> On 10 Dec 2015, at 14:23, akas...@sigaint.org wrote: > > I'm running some bridges on VPS where I set 10GB monthly limit. I never > come close to the quota, but the bridges reset with a new port and new > stats every accounting period. This is undesirable because it means > people who wrote down my bridge and port will no longer be able to > connect. And Atlas take 6 more days to mark the bridge as fast again. This is a known issue, see Trac Ticket #3511 Automatically chosen published ports should be stable https://trac.torproject.org/projects/tor/ticket/3511 <https://trac.torproject.org/projects/tor/ticket/3511> (We'd love a patch to fix this!) > I like port diversity, but monthly switch seems excessive if 25% of every > month is spent resetting stats. Please try setting ORPort to a value other than "auto". And, if you're using them, also set pluggable transport port(s) explicitly. For example: ORPort 12345 ServerTransportListenAddr obfs4 :23456 > Can I set a longer accounting period, like 6 months? Not in the current version of tor. > Failing that, what's > the risk if I just get rid of the quota? Throttle rate of 200KB/s could > add to 4TB/mo in worst case, which will get a VPS account killed. What's > a more realistic worst case if I keep 200KB throttle with no monthly > accounting? I think setting ports to known values is your best bet here. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Custom bandwith for different time ranges
> On 8 Dec 2015, at 12:11, Green Dream <greendream...@gmail.com> wrote: > > > any of these are very likely to wreck your consensus weight situation > > From a Tor user's perspective, if a relay is periodically dropping to 250 > Kb/s, a low consensus weight for that relay is probably a good thing. Two other possibilities: * always run the relay at 250kbps * run a bridge instead (I don't know if 250kbps is still considered enough for a bridge) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Custom bandwith for different time ranges
> On 7 Dec 2015, at 09:39, ajs124 <t...@ajs124.de> wrote: > > Hey, > > the easiest solution that comes to mind is a cronjob/systemd timer/whatever > that modifies the config file and sends a SIGHUP to tor to trigger a config > reload. > > I'm not very familiar with the codebase, so I can't guarantee that reloading > the config file applies new (Relay)BandwithRate settings, but from the > glances I took at the code it does seem like it should do it. > Please someone verify or falsify this claim. Reloading the config file changes all the settings. For the few settings where it doesn't, tor will warn you, or refuse to reload the config. > > ajs124 > > On Sun, 6 Dec 2015 21:38:05 +0100 > Zalezny Niezalezny <zalezny.niezale...@gmail.com> wrote: > >> Hi All, >> >> this is my first post on this list so warm welcome to every one a specialy >> to Tor developers. >> >> On my servers I`m running paralllel prod servers with tor relays on the >> separate IP. >> I`m supporting tor network for free with high speed tor relays but I need >> to customize the time when my server will share 100% of its resources for >> tor and when traffic will be limited. >> >> >> Is it possible to schedule the time when bandwith will looks as follow: >> >> 8:00 - 18:00 - Tor relay bandwith 250kb/s >> >> 18:00 - 8:00 - Tor relay bandwith 10 000kb/s >> >> >> How may I schedule this in tor relay ? Is it possible to limit traffic on >> the client or I need to do it on my firewall ? >> >> >> Thanks in advance for any feedback. > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] VPS/Tor Almost There
Hi Kurt, You need to know the public IPv4 address of your relay. Until you have the address correct, it's hard to tell whether you need to open any ports or not. > Dec 05 21:17:46.000 [notice] Your IP address seems to have changed > to 167.114.35.28 (METHOD=INTERFACE). Updating. Dec 05 21:17:46.000 > [notice] Our IP Address has changed from 142.4.217.95 to > 167.114.35.28; rebuilding descriptor (source: METHOD=INTERFACE). > Dec 05 21:18:42.000 [notice] Your IP address seems to have changed > to 142.4.217.95 (METHOD=GETHOSTNAME HOSTNAME=ca3.pulseservers.com > <http://ca3.pulseservers.com/>). > Updating. Dec 05 21:18:42.000 [notice] Our IP Address has changed > from 167.114.35.28 to 142.4.217.95; rebuilding descriptor (source: > METHOD=GETHOSTNAME HOSTNAME=ca3.pulseservers.com > <http://ca3.pulseservers.com/>). Dec 05 > 21:18:43.000 [notice] Self-testing indicates your ORPort is > reachable from the outside. Excellent. Publishing server > descriptor. Dec 05 21:38:37.000 [warn] Your server > (142.4.217.95:9030) has not managed to confirm that its DirPort is > reachable. Please check your firewalls, ports, address, /etc/hosts > file, etc. Dec 05 21:58:37.000 [warn] Your server > (142.4.217.95:9030) has not managed to confirm that its DirPort is > reachable. Please check your firewalls, ports, address, /etc/hosts > file, etc. > I've gotten this far, not being much good at networking I can't tell > where the problem lies.. do I need to forward something? > Tor is receiving two different IP addresses using two different methods of working out your VPS IP address: * gethostname() on ca3.pulseservers.com <http://ca3.pulseservers.com/> returns 142.4.217.95 * an OS-specific interface address system call returns 167.114.35.28 Please find out from your admin which IPv4 address you should use, and specify it using the "Address" option in your torrc. (Or, alternately, make a connection to http://www.myipaddress.com/show-my-ip-address/ <http://www.myipaddress.com/show-my-ip-address/> or similar from the VPS, and look at the address it returns.) > On 7 Dec 2015, at 03:15, Kurt Besig <kbe...@socal.rr.com> wrote: > > The VPS isn't allowing Ports 9001 and 9030 > Should I investigate further getting my iptables up and running or > just contact the admin and have them allow the ports? Once you know the correct IPv4 address, try launching Tor again, and give it 20 minutes to check reachability. If it still complains that it can't reach your ORPort or DirPort, then ask your admin if they need to open ports to a VPS. (From your previous posts, it looks like the ports are not being blocked on the VPS OS itself.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] VPS Connection Refused
> On 3 Dec 2015, at 09:44, Kurt Besig <kbe...@socal.rr.com> wrote: > > After setting up Tor and tor-arm on the VPS I'm not able to connect > with this error: unable to reconnect (connection refused. Is the > ControlPort Enabled?) > I've edited ~/home/.arm/torrc and /etc/tor/torrc un-commenting the > ControlPort 9052 and all the other typical ports, etc.. I don't have enough information to be sure what's going on: What control port is tor actually connected to? (Try "lsof -p " or "netstat") Can "telnet" or "nc" connect to the port? Does your VPS provider block connections from localhost to localhost by default? (This is an unusual config, that may be why the advice you received didn't help.) What else have your tried? > Obviously I'm > not able to forward or enable ports on the VPS, so do I need to ask > the admin to make some changes? Possibly. Some VPSs let you modify the firewall settings yourself. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nagios/Icinga plugin check_tor_bandwidth for gathering bandwidth data
> On 26 Nov 2015, at 18:07, Josef 'veloc1ty' Stautner <he...@veloc1ty.de> wrote: > > Hi Tim, > > you hit me hard today because I didn't think about the privacy of the users > :-) Sorry about that :-( > But the data points for read and write are just average values and the time > series database also only stores the average values. So I don't think that > just by looking at the graph you can track specific Hidden Services or make > other attempts. They would get better precision if they trace the IP of the > server. I think you're right, but it depends on your threat model: * an adversary with access to a router/IXP near your server could get precise bandwidth figures (bytes/second) that way; * an adversary anywhere in the world could see averaged bandwidth figures (kilobytes?/minute) using your graph. I could imagine your users facing either type of adversary. But there might be ways to work around that: * a public graph could average bandwidth over the time period used on Globe (6 hours), or * a private graph could provide as much detail as you like, and be made available over password-protected HTTPS, or as a hidden service with client authentication. Tim > Am 25.11.2015 um 23:33 schrieb Tim Wilson-Brown - teor: >> >>> On 26 Nov 2015, at 05:36, Josef Stautner < >>> <mailto:he...@veloc1ty.de>he...@veloc1ty.de <mailto:he...@veloc1ty.de>> >>> wrote: >>> >>> Hello @all, >>> >>> (I'm not sure if you guys are interested in a topic like this) >>> I wrote a perl script to gather bandwidth data from my Tor exit relay. >>> The script connects to the Tor control socket, fetches the running >>> config to extract the bandwidth limits and the reject rule count. >>> Afterwards the last 60 bw-cache entries are fetched and average values >>> are built for bandwidth in and out. >>> All this performance data is then forwarded to Nagios/Icinga where you >>> can do anything with that values. >>> >>> Every 30 minutes a cronjob renders the graph showing the datapoints of >>> the last 6 houres and uploads the resulting image to my website. You can >>> find the image here (Hint: The values for in and out are stacked): >>> https://blog.veloc1ty.de/bandwidth-large.png >>> <https://blog.veloc1ty.de/bandwidth-large.png> >>> >>> The source of the script can be found here on GitHub: >>> https://github.com/vlcty/check_tor_bandwidth >>> <https://github.com/vlcty/check_tor_bandwidth> >>> It's released under the GPLv3 >>> >>> Maybe somebody will find it usefull :-) >> >> Hi Josef, >> >> Thanks for creating this tool - it looks like a great way for operators to >> keep an eye on their relay. >> >> But I wonder about the privacy implications of making a relay's >> high-resolution bandwidth figures public. >> For example, attacker can correlate a traffic-based attack on a hidden >> service, with a traffic peak on its Guards. >> (I am not sure if any similar attack applies to Exits, or any other role >> Exits may have.) >> We previously moved to a bandwidth statistics interval of 6 hours for this >> reason. >> (That's why the 3 days and 1 month bandwidth graphs are empty on Globe.) >> >> You lose a certain amount of precision moving to a graph, rather than >> reporting exact figures in a data file. >> But I'm not sure if that's enough to avoid the attack I described above. >> >> Tim >> >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP 968F094B >> >> teor at blah dot im >> OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F >> >> >> >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays> > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How to prevent netscan usage?
Hi Roland, > On 26 Nov 2015, at 14:50, ZEROF <secur...@netmajstor.com> wrote: > > Hi, > > First rule is to use some firewall, 2nd is to disable that port for few days. > You will not lose exit flag becuase of this To retain the exit flag, you need to allow exiting on at least two of 80, 443, 6667, to at least a /8 IPv4 netblock. So if you disable port 80, please consider checking you have port 6667 enabled. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nagios/Icinga plugin check_tor_bandwidth for gathering bandwidth data
> On 26 Nov 2015, at 05:36, Josef Stautner <he...@veloc1ty.de> wrote: > > Hello @all, > > (I'm not sure if you guys are interested in a topic like this) > I wrote a perl script to gather bandwidth data from my Tor exit relay. > The script connects to the Tor control socket, fetches the running > config to extract the bandwidth limits and the reject rule count. > Afterwards the last 60 bw-cache entries are fetched and average values > are built for bandwidth in and out. > All this performance data is then forwarded to Nagios/Icinga where you > can do anything with that values. > > Every 30 minutes a cronjob renders the graph showing the datapoints of > the last 6 houres and uploads the resulting image to my website. You can > find the image here (Hint: The values for in and out are stacked): > https://blog.veloc1ty.de/bandwidth-large.png > > The source of the script can be found here on GitHub: > https://github.com/vlcty/check_tor_bandwidth > It's released under the GPLv3 > > Maybe somebody will find it usefull :-) Hi Josef, Thanks for creating this tool - it looks like a great way for operators to keep an eye on their relay. But I wonder about the privacy implications of making a relay's high-resolution bandwidth figures public. For example, attacker can correlate a traffic-based attack on a hidden service, with a traffic peak on its Guards. (I am not sure if any similar attack applies to Exits, or any other role Exits may have.) We previously moved to a bandwidth statistics interval of 6 hours for this reason. (That's why the 3 days and 1 month bandwidth graphs are empty on Globe.) You lose a certain amount of precision moving to a graph, rather than reporting exact figures in a data file. But I'm not sure if that's enough to avoid the attack I described above. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] warning in my relay log
> On 24 Nov 2015, at 01:54, DARKNET.IT <i...@darknet.it> wrote:
>
> I have changed server and tor version (from Tor 0.2.6.10 to Tor
> 0.2.7.5). My relay works but I have this warning:
> "http status 400 ("Looks like your keypair does not match its older
> value.") response from dirserver '208.83.223.34:443'. Please correct."
> This is my relay fingerprint: 59573AB90614D929360C7D9BCBF3313497A22AA2
> What means and what I have to do? The keys for me is correct.
Your relay now has two keys: a RSA 1024-bit key (existing) and an ed25519 key
(new).
Your fingerprint is generated from the RSA key.
Directory authorities ensure that each RSA key and ed25519 key pair only ever
appear together.
Did you have an ed25519 key, and then delete it? (or fail to restore it from a
backup?)
Or perhaps there is a bug in the authority's handling of ed25519 key pairs.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
