- tor-relays - lists.torproject.org

denetron.com Tor Relays MyFamily Configuration
by nusenu 12 Jan '18

12 Jan '18

Hello, thanks for running Tor relays! Please do not forget to set your "MyFamily" configuration parameter on all your relays, so Tor clients are not at risk of using your relays in multiple positions in a single circuit. Some more background: https://hackernoon.com/some-tor-relays-you-might-want-to-avoid-5901597ad821 https://nusenu.github.io/OrNetStats/endtoend-correlation-groups Let us know if you need any help with this. thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Faravahar - Scheduled Maintenance - Thursday, January 11, 2018 at 18:00:00 UTC to 22:00 UTC
by Sina Rabbani 11 Jan '18

11 Jan '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Scheduled Maintenance Thursday, January 11, 2018 at 18:00:00 UTC to 22:00 UTC Dear Tor Network, I am upgrading/replacing the hardware for Faravahar, and would like to announce a maintenance window: Scheduled Start: Thursday, January 11, 2018 at 18:00:00 Scheduled End: Thursday, January 11, 2018 at 22:00:00 During this event the server will be out of service and unavailable. I will reply to this email with updates when the work begins and upon completion. All the best, Sina -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJaVVAaAAoJEMeylP64yITyeR8P/jr13qhdtK/zWja9Ybp6NbBq +jWBSes/CGxLGtIRs/DIXF6jlhaPfM+yO/bhQ3MJvpa5ls50EPQhzEuUnbM3Zxtv 586cgclupXtDXyu8n7wbJRelmbRZ7Ef7mQDc9IaNU3J4UgzsS0bNghIKO1gfq2rc HK97JIqnGyPDjzrPvFatzdKWAkmIk6TR4c6zuCcHZqNChQxSkOge0acOo69fusL/ 4TQr69GOTklV6N3YVvo8OLzUlWNGGj1CHVN6nJD11NwyZFrQ6kC1PfaPcUNs0CUB ecge5FBXXFb1gDA9gr2THAdw++bmOZwaKKgqgyyU6qFhQkOHAnHhTh5Ef0YBIwXg l4m4FW+u91yfv2rHaXF2K4DgjhgKkjfmmsmT2NIIE7uCxtr8otmJQSyy6W8awn2Y ymoMUfCbqUD3QNUHU90PJmTSlzK2+Asp2cd8PdiIILXsmwVq+JBt09MnT/lDO/UH kxnNTK7VnVChpef40z1JyZKyGOeXc/a4O5VvyfvYDohe9sBiiINdfGz7RA6+BOsE ChUp8PiGimyWZpHVO7ccZyWya3mTT43HRJjr3U0LoZNBb1S/CwYre1B/7e2M3i/D WYOQc/ubTuw6ZOJ79QMxPdUR76WLsJi/ULZ1iqEwdyagg/jnUsDNMRYp4da12kij iESAh7F4Tom7zeh2xHh1 =qe70 -----END PGP SIGNATURE-----

1 2

Failing because we have 1354 connections already.Please read doc/TUNING for guidance.
by rush23＠gmx.net 10 Jan '18

10 Jan '18

2 1

Nyx reported speed
by John D. McDonnell 09 Jan '18

09 Jan '18

I'm not sure if reporting is off or something isn't configured right or whatever it could be, but when running nyx, it is telling me that the measured rate is 229.0 B/s which to me, sounds ridiculously slow. Where is it getting the measured rate from? Is it a calculation on how much data is passing in a given time or some sort of speed test from another relay or where? While I've used Tor off and on for several years, I never ran a relay until now and I'm still not certain on several aspects, though I keep digging to make sure I can supply the best exit relays I can. (I currently host 2 exit relays and hope to bring up 3 more in the near future if I can find hardware to run them on. Though I may make one a bridge.) I have some spare internet connections that are provided to us that are 25/5 connections. I configured torrc with a 500KB/s limit with 600KB/s bursting as this should work nicely to use ~4Mbps of the 5Mbps that the connection supports and allows me some bandwidth to be able to connect to the machines for monitoring and troubleshooting as well as more than enough bandwidth for downloading updates and such. The line in nyx that I'm referring to is: Bandwidth (limit: 500 KB/s, burst: 600 KB/s, measured: 229.0 B/s): Where is it getting that 229.0 B/s rate and is there anything I can do to get it closer to the 500KB/s I am trying to share. Granted, I am using a Linksys e1200 and Belkin something-or-other that I can't remember off the top of my head running DD-WRT as routers in front of the servers. (I've pondered removing the router and just connecting the server directly to the internet and relying on pf for my firewalling, but I can't do that at the one location as I also have a couple other things connected to it. Both routers are higher end consumer routers with 32MB of RAM and has 32768 for maximum ports. (Currently just under 3000 active IP connections as I'm typing this e-mail.) I might just try this on my one exit to see if this is the bottleneck I'm hitting or if there's something else affecting it. When I had first put this in place, I was using an older Netgear ProVPN router of some sort, but I swapped it out due to it flagging NTP traffic as unknown even though my server was initiating the NTP requests. But I was maintaining 200KB/s+ connections fairly consistently. It now ranges all over the place and I'm not sure if that's an issue on my end or just part of the lifecycle of a relay. I just recently rebooted the machine this happened to pop up in the nyx log window as I was looking at this: 12:33:09 [NOTICE] Heartbeat: Tor's uptime is 4 days 23:59 hours, with 1928 circuits open. I've sent 37.89 GB and received 37.00 GB. To me, that seems a too low, but I've not sat down to do the math and maybe that's a good statistic for 5 days at 4Mbps. I'd appreciate any tips and pointers you can send my way. And if the consumer routers are the issue, I can move my one exit relay to one of the other connections I have and not use it at the location (or just run one that's slower) where I do use this backup internet connection. (It's handy to have a network that's not part of our internal network for testing.) Thanks for sticking with me through this whole e-mail and I apologize for rambling and jumping around a bit. I'm sure I left out some stuff and didn't clarify something else or something wasn't clear, so if you need more information, just ask. Thank you, John Penn Cambria School District This e-mail and any files transmitted with it are confidential and intended only for the person or entity to which it is addressed. If you have received this email in error, please notify the sender immediately via email and delete this email along with any attachments from your system. Any unauthorized or improper disclosure, copying, distribution, or use of the contents of this e-mail and attached documents is strictly prohibited. The views and opinions of this email or attachments are reflections of the author and are not necessarily the views and opinions of Penn Cambria School District. We do not accept responsibility or liability for any loss or damage from the receipt of this email, its use, or for any errors or omissions. www.pcam.org<http://www.pcam.org>

3 8

Configuring your relay
by Tommy Collison 09 Jan '18

09 Jan '18

Hi there, I'm Tor's writer/editor. We just got a question on Twitter that I'm stumped on, and I had a quick look through the documentation and didn't find anything. Can anyone shed some light? - Can you set up a relay to provide more bandwidth during specified hours? (e.g. more at night, less during the day.) - Is there a way of configuring the relay to work only on certain days? I assume not, and that this would have to be done manually, maybe with cron? Cheers, TC

3 2

Relay not listed in atlas
by Fabian A. Santiago 09 Jan '18

09 Jan '18

One of my relays is no longer listed in atlas. I'm curious why and how can I go about examining the issue? It had been running for several weeks at this point seemingly fine. My other relay lists it as an alleged family member but it's id is listed in a different color (yellow). Is this part of the ddos issue I've seen spoken of here? The server is accessible and Tor is running. System stats look fine. Any ideas? Thanks. -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

3 5

Updated Fallback Directory Mirrors
by teor 09 Jan '18

09 Jan '18

Dear Relay Operators, Thanks to everyone who opted-in their relays as fallback directory mirrors. We rebuilt the list of fallbacks on the weekend. [0] The new list will come out in Tor 0.3.2.9. It will be backported to all supported Tor releases. [1] The FallbackDir flags on Consensus Health [2] have been updated. The flags on Relay Search (Atlas) [3] might take a few days to update. Don't worry if your relay missed out this time. It's still helping Tor users. And we will rebuild the fallback list again in 6-12 months time. You can keep replying to this thread to opt-in your relays. If you have multiple relays, you can opt-in as many as you like. (We picked up to 7 per operator this time, and we may pick more next time.) We are tracking fallback changes in this ticket [4]. T [0]: https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc https://trac.torproject.org/projects/tor/ticket/24801 [1]: 0.2.9, 0.3.0, and 0.3.1. (0.2.5 doesn't have the fallback feature). See https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… [2]: https://consensus-health.torproject.org/graphs.html [3]: For example, this relay is a new fallback: https://atlas.torproject.org/#details/001524DD403D729F08F7E5D77813EF12756CF… [4]: https://trac.torproject.org/projects/tor/ticket/24805 -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------

2 1

what are these spikes
by Paul Templeton 08 Jan '18

08 Jan '18

Hi all, just a query - I get these unusual spikes on https://atlas.torproject.org/#details/867B95CACD64653FEEC4D2CEFC5C49B462030… (have a look at the three month chart) and I notice some of the other AU relays do the same. can anyone tell me what they are???? Paul

2 2

*BSD bridge operators
by George 08 Jan '18

08 Jan '18

For anyone running *BSD bridges that wasn't aware, there are obfs4proxy packages/ports available for each of the BSDs: FreeBSD as security/obfs4proxy-tor NetBSD as net/obfs4proxy OpenBSD as net/obfs4proxy DragonFlyBSD as security/obfs4proxy-tor For assisting aggressively censored users, bridges really should consider configuring obf4sproxy. g -- 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682

2 1

Really strange
by r1610091651 07 Jan '18

07 Jan '18

Outcome of a script to count # connections /24 range 11 188.214.30.* 20 37.48.104.* 22 37.48.86.* 33 5.79.72.* 48 212.32.226.* 97 212.32.239.* 197 149.202.66.* 294 5.79.103.* 303 198.7.59.* 358 207.244.110.* 380 162.210.192.* 394 207.244.70.* 395 199.115.112.* 499 54.36.51.* And that on my lowly relay (consesus of 1k) Other relays seeing this too?

3 10

Re: [tor-relays] [tor-dev] Relay diversity master thesis
by grarpamp 07 Jan '18

07 Jan '18

On Sun, Jan 7, 2018 at 8:29 AM, teor <teor2345(a)gmail.com> wrote: >> On 22 Dec 2017, at 11:23, Robin Descamps <robin.descamps(a)outlook.com> wrote: >> May I ask you advices/feedback about this master thesis plan? >> The master thesis plan: https://drive.google.com/open?id=1XEOSS29owavKJ_cJJAVaPiJe34Ez6XXx >> The poster: https://drive.google.com/open?id=1BlF2U-Kexyz6ihVSqvsVHv4PUsvXATc4 > In particular, operators that could perform end-to-end correlation? > Have you considered the relay's Operating System? If considering as yet non tor daemon, non measured, non consensus voted things like operators and OS, then you should extend research into similar meta parameters about the relays themselves such as datacenter hosted vs cable/dsl/fiber "home" relays, country locations, opposing legal jurisdictions, operation by "known" or "trusted" operators / entities or not, by working / fake / no contact info, by any PKI Web Of Trust asserted among operators, funding sources, employer / corporate / political / other affiliations, statistical analysis of historical relay "presence" on the network (add/drop/uptime, nicknames, movement, versions, bulk turnups, correlation groups, etc), and many more possible metas that people should think up and add to this list. That research then followed by development of third party subscription lists of categorized / ranked relays the user or tor daemon may further pluggably select from when choosing nodes to path through. There have been posts on tor-relays@ and tor-talk@ that mention more about these sorts of meta parameters. AFAIK, no one has done any research into them or their potential impact / benefits, whether to particularly affected, or for plain preferential choice users, or to the network as a whole. So the chance of a first good paper in the area awaits whoever does that meta analysis project. [xpost for open project oppurtunity]

1 0

Fallback Directory Mirror changed
by cxx 06 Jan '18

06 Jan '18

Hi there, took a while longer than expected, but my relay has now moved to a new IP address, it's running on 37.157.255.35 now, so it could be re-added to the list. Regards cxx > > On 16 Nov 2017, at 15:05, teor <teor2345(a)gmail.com> wrote: > >> On 15 Nov 2017, at 21:13, cxx <tor(a)cxx.rocks> wrote: > >> I have to move my node to another server, as this one is running > >> unstable in the past weeks. Unfortunately, I can't keep the ip-address > >> 217.79.190.25, which is in the the list of fallback > >> directory mirrors, so the IP should be removed or changed. > > Thanks for letting me know. > > We are tracking changes in this ticket, when we get enough, someone > > will do them all: > > https://trac.torproject.org/projects/tor/ticket/22321#comment:10 > > It looks like your relay hasn't moved. > We've removed it from the list for now. > When it gets its new address, please email tor-relays, and CC me.

1 0

collecting info on Wikipedia blocking non-exits
by Alison Macrina 05 Jan '18

05 Jan '18

Hi friends, I'd like to collect some anecdata about this issue regarding Wikipedia blocking edits from Tor non-exit relays: https://trac.torproject.org/projects/tor/ticket/24758 If you run a non-exit relay, would you be so kind as to go to wikipedia.org from that IP, click "edit" on any page, and report to me off-list if your relay is blocked or not? In your message, please give me your relay address and let me know if it's ever functioned as an exit before. Thank you! Alison -- Alison Macrina Community Team Lead The Tor Project

6 5

Marker branch for current tor release(s)
by Andreas Krey 05 Jan '18

05 Jan '18

Hi everybody, https://www.torproject.org/download/download.html.en in the source code 'tab' states the current stable and alpha version of tor. Would it be possible to publish the current states as branches 'stable' and 'alpha' (or 'testing', or 'unstable') in the git repo? That would help us tor-from-source builders to just fetch the repo, and if the respective branch changes, to rebuild and redeploy. Looking for a new release tag or screen-scraping said web page is a bit hairy, and feels unnecessary. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds(a)*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800

1 0

Setting myfamily
by Fabian A. Santiago 05 Jan '18

05 Jan '18

When setting myfamily on a particular relay, do you list itself plus others or only others? I ask because it's my understanding that you set itself + others but on atlas, for one relay I see in its family listing, it shows itself plus the 2nd one. And therefore it receives a (3) after it's nickname in the atlas listing. On the other relay it only lists the other in family listing. And it has a (2) in it's atlas listing next to nickname. They're both set the same as in they each list themselves + the other. Thanks. -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

6 5

Can't get the exit flag
by Guilherme Rigon 04 Jan '18

04 Jan '18

hello i'm running a node and it's supposed to be an exit node, but i don't know why it's not getting the exit flag. Fingerprint: AFD3E441204DD828FD1EF1401742D379814D2A55 Tor version 0.3.1.9 (git-df96a13e9155c7bf). torrc: https://pastebin.com/R9qmYiX5 Any tips to fix that? -- ‌

3 5

Circuit padding timeouts
by Rick 04 Jan '18

04 Jan '18

Hello list, I'm curious as to the significance of the log notice: "Circuit padding timeout scheduled X ms in the past". As the he load on my Guard has increased, these have become more frequent and the timeout longer - approaching 300 seconds. I'm not seeing any other warnings and the relay is stable. Is this reason for concern? Rick

4 3

Become a Fallback Directory Mirror
by raltullou＠posteo.org 04 Jan '18

04 Jan '18

Hope it's not too late :) 11DF0017A43AF1F08825CD5D973297F81AB00FF3

1 0

Happy New Year!
by Shari Steele 02 Jan '18

02 Jan '18

Hey all. I'd like to take this opportunity to thank each and every one of you for working on Tor over the past year(s). We are entering 2018 in really great shape, and we would not be here without your hard work. - The Tor network and browser teams have grown over the past year and are full of amazing talent. They've added new features and tightened security in 2017, and they'll be focused on increasing our usability and mobile adoption in 2018. - The whole Tor Project staff grew quite a bit, and we hired several long-time contractors and volunteers into employee status. - Our financials are stable. We've started receiving more funding from non-US government sources, and our end-of-year campaign looks to have been a big success. We won't know the exact totals until we get into the office tomorrow and add in all of the checks we've received over the past week, but even without those checks, this has been our best end-of-year fundraising campaign yet. - We had two great all-hands meetings in 2017 in Amsterdam and Montreal. - We have been strengthening our important relationship with Mozilla. Thanks to everyone who contributes to making Tor so great, whether you are an employee, contractor, or volunteer. I'd like to extend a special thanks to some of you who we don't thank nearly enough--those of you who run the Tor network as relay operators and directory authorities and countless other volunteer roles. We couldn't do this without you! I wish you all a healthy and happy 2018! Shari *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~ Shari Steele Executive Director The Tor Project ssteele(a)torproject.org <mailto:ssteele@torproject.org> public key: 69B4 D9BE 2765 A81E 5736 8CD9 0904 1C77 C434 1056 "Everything that is really great and inspiring is created by the individual who can labor in freedom." - Albert Einstein

3 2

Tor Advocacy, Political & Artistic
by Kenneth Freeman 29 Dec '17

29 Dec '17

I've recently touted establishing a Tor exit node at the inaugural Boise organizing committee of the Democratic Socialists of America. The idea was considered esoteric, but such anonymity craft is useful for activists of all stripes. Too, performing artists (neo-burlesque, LGBTQ comics, etc.), punks and anarchists have also expressed interest in Tor. I have been told that Tor is conceptually difficult to wrap your head around, but these are useful mission fields.

4 4

Debian Stretch (Raspbian): Tor daemon fails to complete launching procedure, endless cycling.
by Ralph Wetzel 28 Dec '17

28 Dec '17

2 2

Q about: The IPv4 ORPort address <IP> does not match the descriptor address
by Stijn Jonker 28 Dec '17

28 Dec '17

Hi All, As a follow-up to the thread, "Can it be done? - IPv6 only Relay" I linked the new OpenBSD Relay via an IPv4 over IPv6 tunnel to the other relay I operate. So there is: SJC01 / 328E54981C6DDD7D89B89E418724A4A7881E3192 and now SJC02 / 366BC592BC0154C0CD1D35C0E77D8F2C7F0B843E Both share the same public IP, as it's on atlas :-) I can see no issues sharing: SJC01 ORPort is on 80.127.117.180:443 / [2001:985:e77:10::4]:443 (DirPort 80) SJC02 ORPort is on 80.127.117.180:993 / [2001:985:e77:10::6]:993 (DirPort 8080) What I can't seem to get rid of is the warning: The IPv4 ORPort address 80.127.177.180 does not match the descriptor address 80.127.117.180. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'. I think I tried every combo of ORPort NoListen/NoAdvertise and Address/OutboundBindAddress, but I don't seem to be able to get rid of this. What I have now is: ORPort [2001:985:e77:10::6]:993 ORPort <<INTERNAL IP>>:993 NoAdvertise ORPort 80.127.177.180:993 NoListen Address 80.127.117.180 OutboundBindAddress <<INTERNAL IP>> OutboundBindAddress [2001:985:e77:10::6] Port 993 and 8080 are one-on-one pushed through to the new node with DNAT/Port forward from the 80.127.117.180. This on: [userhost ~]$ tor --version Tor version 0.3.1.9 (git-727d3f1b5e6eeda7). [userhost ~]$ uname -a OpenBSD host 6.2 GENERIC#306 amd64 The daemon reports "Self-testing indicates your ORPort is reachable from the outside. Excellent." / "Self-testing indicates your DirPort is reachable from the outside. Excellent. Publishing server descriptor." so that seems to be A-OK. Any suggestions (or should I "just" ignore this as mentioned on tor-dev @ Tue Jan 24 04:20:27 UTC 2017 in subject: "[tor-dev] log: ORPort/DirPort address does not match descriptor address")? Thx, Stijn

2 2

Re: [tor-relays] Please Confirm Changed Fallback Details
by teor 28 Dec '17

28 Dec '17

Thank you to everyone who has replied to the fallback threads. We're tracking the fallback changes here: https://trac.torproject.org/projects/tor/ticket/22321 Once we've reviewed some list format changes, we'll generate the new list. This will probably happen in the next two weeks. Please email us about new fallbacks at any time. T > On 28 Dec 2017, at 10:34, Casper <fantom(a)fedoraproject.org> wrote: > > Hi teor, > > Yes I had to change the ORport and DirPort for POP3 standard ports, > specially because Let's Encrypt works only with HTTPS ports. And this > time it won't change again, who is using POP3 these days... ^^ > > Merry christmas teor :) > > teor a écrit : >> Hi, >> >> Are you the operator of the following relays? >> >> mkultra - 16102E458460349EE45C0901DAA6C30094A9BBEA >> ParkBenchInd001 - F10BDE279AE71515DDCCCC61DC19AC8765F8A3CC >> Underworld - DC163DDEF4B6F0C6BC226F9F6656A5A30C5C5686 >> Casper03 - 7350AB9ED7568F22745198359373C04AC783C37C >> sputnik - AD19490C7DBB26D3A68EFC824F67E69B0A96E601 >> zwiubel - B0553175AADB0501E5A61FC61CEA3970BE130FF2 >> >> Your relay is on the fallback directory whitelist, and it looks like >> its details have changed. (Or, maybe I wrote them down wrong.) >> >> I tried to contact you a few days ago using the ContactInfo on your >> relay, but I haven't received a response. >> >> Will your relay be around for the next two years? >> Will its IP, ports, and fingerprint stay the same? >> >> Please reply to this email and let us know! >> (If you don't reply, we will assume the change is permanent.) >> >> Thanks >> >> Tim >> >> >> Here is the full list: >> >> Changed fingerprint: >> >> Has OR 163.172.138.22:443 / [2001:bc8:4400:2100::1:3]:443 changed fingerprint from 8664DC892540F3C789DB37008236C096C871734D to 16102E458460349EE45C0901DAA6C30094A9BBEA? >> 163.172.138.22:80 orport=443 id=16102E458460349EE45C0901DAA6C30094A9BBEA ipv6=[2001:bc8:4400:2100::1:3]:443 # mkultra >> >> Changed IPv4: >> >> Has F10BDE279AE71515DDCCCC61DC19AC8765F8A3CC changed IPv4 from 192.99.212.139 to 193.70.112.165? >> 193.70.112.165:80 orport=443 id=F10BDE279AE71515DDCCCC61DC19AC8765F8A3CC # ParkBenchInd001 >> >> Has DC163DDEF4B6F0C6BC226F9F6656A5A30C5C5686 changed IPv4 from 176.158.132.12 to 176.158.236.102? >> 176.158.236.102:9030 orport=9001 id=DC163DDEF4B6F0C6BC226F9F6656A5A30C5C5686 # Underworld >> >> Changed DirPort: >> >> Has 7350AB9ED7568F22745198359373C04AC783C37C changed DirPort from 176.31.191.26:80 to 176.31.191.26:110? >> 176.31.191.26:110 orport=995 id=7350AB9ED7568F22745198359373C04AC783C37C # Casper03 >> >> Gained IPv6 address: >> >> Has AD19490C7DBB26D3A68EFC824F67E69B0A96E601 gained an IPv6 address [2a01:4f8:221:1ac1:dead:beef:7005:9001]:9001? >> 188.40.128.246:9030 orport=9001 id=AD19490C7DBB26D3A68EFC824F67E69B0A96E601 ipv6=[2a01:4f8:221:1ac1:dead:beef:7005:9001]:9001 # sputnik >> >> Has B0553175AADB0501E5A61FC61CEA3970BE130FF2 gained an IPv6 address [2a01:4f8:190:30e1::2]:9001? >> 5.9.147.226:9030 orport=9001 id=B0553175AADB0501E5A61FC61CEA3970BE130FF2 ipv6=[2a01:4f8:190:30e1::2]:9001 # zwiubel >> >> T >> >> -- >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >> ricochet:ekmygaiu4rzgsk6n >> xmpp: teor at torproject dot org >> ------------------------------------------------------------------------ >> > > > > -- > GPG Key ID: 83288189 @ hkp://keys.fedoraproject.org > Empreinte: CC26 692F 5205 AC8F 7912 7783 D7A7 F4C5 8328 8189 > > x509 C.A.: https://dl.casperlefantom.net/pub/root.pem > Empreinte: 0975 864A 2036 0F94 A139 114A D32E 8EBE 30F2 2429 T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

1 0

Recent wave of abuse on Tor guards
by fcornu＠wardsback.org 27 Dec '17

27 Dec '17

Hi I'm the happy maintainer of wardsback : B143D439B72D239A419F8DCE07B8A8EB1B486FA7 As many of us have noticed, many guard nodes are beeing abused by extremely high numbers of connection attempts. Thanks to some of you guys, I manged to put some mitigation in place [0] and I assume many of us did as well. I now sit back with questions and concerns arising : 1) Why didn't we see this abuse wave coming ? We kept replying to reporters of the dreaded "Failing because we have XXX connections already. Please read doc/TUNING for guidance" about how they could amend their config to accept more connections. Although the 'global scale' of those events should have been detected, without most of use assuming it was due to nodes' bad config. 2) We can see on Metrics [1] that guards count is dropping rapidly for a couple weeks now. Presumably because many guard maintainers gave up on restarting their crushed node. (I never will. Even though my Metrics graph shows I've also been in trouble) 3) What could we do to better detect those 'attacks' and spread the word to fellow maintainers about how to mitigate / correct the situation ? I must admit I don't have a valuable clue about how things can technically be improved, but I humbly wanted to share a few thought here. Peace [0] : https://lists.torproject.org/pipermail/tor-relays/2017-December/013846.html [1] : https://metrics.torproject.org/relayflags.html?start=2017-09-21&end=2017-12… -- Frédéric CORNU

12 19

Please Confirm Changed Fallback Details
by teor 27 Dec '17

27 Dec '17

Hi, Are you the operator of the following relays? mkultra - 16102E458460349EE45C0901DAA6C30094A9BBEA ParkBenchInd001 - F10BDE279AE71515DDCCCC61DC19AC8765F8A3CC Underworld - DC163DDEF4B6F0C6BC226F9F6656A5A30C5C5686 Casper03 - 7350AB9ED7568F22745198359373C04AC783C37C sputnik - AD19490C7DBB26D3A68EFC824F67E69B0A96E601 zwiubel - B0553175AADB0501E5A61FC61CEA3970BE130FF2 Your relay is on the fallback directory whitelist, and it looks like its details have changed. (Or, maybe I wrote them down wrong.) I tried to contact you a few days ago using the ContactInfo on your relay, but I haven't received a response. Will your relay be around for the next two years? Will its IP, ports, and fingerprint stay the same? Please reply to this email and let us know! (If you don't reply, we will assume the change is permanent.) Thanks Tim Here is the full list: Changed fingerprint: Has OR 163.172.138.22:443 / [2001:bc8:4400:2100::1:3]:443 changed fingerprint from 8664DC892540F3C789DB37008236C096C871734D to 16102E458460349EE45C0901DAA6C30094A9BBEA? 163.172.138.22:80 orport=443 id=16102E458460349EE45C0901DAA6C30094A9BBEA ipv6=[2001:bc8:4400:2100::1:3]:443 # mkultra Changed IPv4: Has F10BDE279AE71515DDCCCC61DC19AC8765F8A3CC changed IPv4 from 192.99.212.139 to 193.70.112.165? 193.70.112.165:80 orport=443 id=F10BDE279AE71515DDCCCC61DC19AC8765F8A3CC # ParkBenchInd001 Has DC163DDEF4B6F0C6BC226F9F6656A5A30C5C5686 changed IPv4 from 176.158.132.12 to 176.158.236.102? 176.158.236.102:9030 orport=9001 id=DC163DDEF4B6F0C6BC226F9F6656A5A30C5C5686 # Underworld Changed DirPort: Has 7350AB9ED7568F22745198359373C04AC783C37C changed DirPort from 176.31.191.26:80 to 176.31.191.26:110? 176.31.191.26:110 orport=995 id=7350AB9ED7568F22745198359373C04AC783C37C # Casper03 Gained IPv6 address: Has AD19490C7DBB26D3A68EFC824F67E69B0A96E601 gained an IPv6 address [2a01:4f8:221:1ac1:dead:beef:7005:9001]:9001? 188.40.128.246:9030 orport=9001 id=AD19490C7DBB26D3A68EFC824F67E69B0A96E601 ipv6=[2a01:4f8:221:1ac1:dead:beef:7005:9001]:9001 # sputnik Has B0553175AADB0501E5A61FC61CEA3970BE130FF2 gained an IPv6 address [2a01:4f8:190:30e1::2]:9001? 5.9.147.226:9030 orport=9001 id=B0553175AADB0501E5A61FC61CEA3970BE130FF2 ipv6=[2a01:4f8:190:30e1::2]:9001 # zwiubel T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

1 0