- tor-relays - lists.torproject.org

hviv Tor Relays MyFamily Configuration
by nusenu 14 Feb '18

14 Feb '18

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. https://nusenu.github.io/OrNetStats/endtoend-correlation-groups Some more background: https://hackernoon.com/some-tor-relays-you-might-want-to-avoid-5901597ad821 Let us know if you need any help with this. regards, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Checking dos mitigation
by Felix 14 Feb '18

14 Feb '18

Hi everybody I tried several setups for dos mitigation since the dos code is available and came to the following results, where I think 5) is promising and 2) or 3) are fine. 1) Drops off consensus for 1-2hours and returns w/o hsdir: DOS_CC_CIRCUIT_BURST_DEFAULT 90 DOS_CONN_MAX_CONCURRENT_COUNT_DEFAULT 100 FW: 20 connects per /32 ip, rate limited to 3 per sec. 2) Good (stable): DOS_CC_CIRCUIT_BURST_DEFAULT 50 DOS_CONN_MAX_CONCURRENT_COUNT_DEFAULT 50 FW: 20 connects per /32 ip, rate limited to 3 per sec. 3) Good (stable): DOS_CC_CIRCUIT_BURST_DEFAULT 20 DOS_CONN_MAX_CONCURRENT_COUNT_DEFAULT 20 FW: 20 connects per /32 ip, rate limited to 3 per sec. 4) Too conservative: DOS_CC_CIRCUIT_BURST_DEFAULT 10 DOS_CONN_MAX_CONCURRENT_COUNT_DEFAULT 10 FW: 20 connects per /32 ip, rate limited to 3 per sec. 5) Good (newly): DOS_CC_CIRCUIT_BURST_DEFAULT 50 DOS_CONN_MAX_CONCURRENT_COUNT_DEFAULT 50 FW: 100 connects per /32 ip, rate limited to 15 per sec. Some hack to grab dos ips, their counts and defenses shows the well known ones like a hand full new ones. But no surprises. -- Cheers, Felix

2 2

bridge questions
by Arisbe 14 Feb '18

14 Feb '18

Hello Tor users, I have several quick question: Can bridges use an IPv6 ORPort? Is there any advantage to adding this to my bridges? Has anyone actually seen IPv6 connections on a bridge? Thanks for the feedback...

3 2

[err] tor_assertion_failed_(): Bug: src/or/connection.c:5113
by Toralf Förster 13 Feb '18

13 Feb '18

Got this today: Feb 13 22:02:49.000 [err] tor_assertion_failed_(): Bug: src/or/connection.c:5113: assert_connection_ok: Assertion (conn->type == CONN_TYPE_EXIT && conn->state == EXIT_CONN_STATE_RESOLVING) || connection_is_writing(conn) || conn->write_blocked_on_bw || (CONN_IS_EDGE(conn) && TO_EDGE_CONN(conn)->edge_blocked_on_circ) failed; aborting. (on Tor 0.3.3.2-alpha efc105716283bbdf) Before I changed the config from ExitRelay 1 IPv6Exit 1 to #ExitRelay 1 #IPv6Exit 1 and a little bit later to ExitRelay 0 IPv6Exit 0 -- Toralf PGP C4EACDDE 0076E94E

2 2

1 circuit using 1.5Gig or ram? [0.3.3.2-alpha]
by starlight.2017q4＠binnacle.cx 12 Feb '18

12 Feb '18

On 12 Feb (19:44:02 UTC), David Goulet wrote: >Wow... 1599323088 bytes is insane. This should _not_ happen for only 1 >circuit. We actually have checks in place to avoid this but it seems they >either totally failed or we have a edge case. > >Can you tell me what scheduler were you using (look for "Scheduler" in the >notice log). > >Any warnings in the logs that you could share or everything was normal? > >Finally, if you can share the OS you are running this relay and if Linux, the >kernel version. Don't know if it's relevant but my relay was hit in similar fashion in December. Running 0.2.9.14 (no KIST) on Linux at the time (no other related log messages, MaxMemInQueues=1GB reduced from 2GB after OOM termination): Dec 15 15:28:52 Tor[]: assign_to_cpuworker failed. Ignoring. Dec 15 15:48:16 Tor[]: assign_to_cpuworker failed. Ignoring. Dec 15 16:39:44 Tor[]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 15 17:39:45 Tor[]: Removed 442695264 bytes by killing 1 circuits; 18766 circuits remain alive. Also killed 0 non-linked directory connections. Dec 15 19:03:22 Tor[]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 15 19:03:23 Tor[]: Removed 1060505952 bytes by killing 1 circuits; 19865 circuits remain alive. Also killed 0 non-linked directory connections. More recently (and more reasonably, MaxMemInQueues=512MB), running 0.3.2.9: Feb 4 20:12:39 Tor[]: Scheduler type KIST has been enabled. Feb 6 08:12:41 Tor[]: Heartbeat: Tor's uptime is 1 day 11:59 hours. I've sent 29.00 MB and received 364.99 MB. Feb 6 14:04:43 Tor[]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Feb 6 14:04:43 Tor[]: Removed 166298880 bytes by killing 2 circuits; 20213 circuits remain alive. Also killed 0 non-linked directory connections. Feb 6 14:11:17 Tor[]: Heartbeat: Tor's uptime is 1 day 17:59 hours, with 20573 circuits open. I've sent 910.29 GB and received 902.58 GB. Feb 6 14:11:17 Tor[]: Circuit handshake stats since last time: 1876499/3018306 TAP, 4322015/4322131 NTor. Feb 6 14:11:17 Tor[]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 1 v3 connections, and 23846 v4 connections; and received 6 v1 connections, 7844 v2 connections, 11906 v3 connections, and 214565 v4 connections. Feb 6 14:12:41 Tor[]: Heartbeat: Tor's uptime is 1 day 17:59 hours. I've sent 31.62 MB and received 420.63 MB. Feb 6 14:22:50 Tor[]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Feb 6 14:22:50 Tor[]: Removed 181501584 bytes by killing 2 circuits; 19078 circuits remain alive. Also killed 0 non-linked directory connections. Feb 6 15:01:50 Tor[]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Feb 6 15:01:50 Tor[]: Removed 105918912 bytes by killing 1 circuits; 19679 circuits remain alive. Also killed 0 non-linked directory connections. Feb 6 15:46:24 Tor[]: Channel padding timeout scheduled 157451ms in the past. Feb 6 19:30:36 Tor[]: new bridge descriptor 'Binnacle' (fresh): $4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2~Binnacle at 108.53.208.157 Feb 6 20:11:17 Tor[]: Heartbeat: Tor's uptime is 1 day 23:59 hours, with 18045 circuits open. I've sent 1043.74 GB and received 1034.65 GB. Feb 6 20:11:17 Tor[]: Circuit handshake stats since last time: 260970/368918 TAP, 3957087/3957791 NTor. Perhaps this indicates some newer KIST mitigation logic is effective.

1 0

1 circuit using 1.5Gig or ram? [0.3.3.2-alpha]
by Stijn Jonker 12 Feb '18

12 Feb '18

Hi all, So in general 0.3.3.1-alpha-dev and 0.3.3.2-alpha running on two nodes without any connection limits on the iptables firewall seems to be a lot more robust against the recent increase in clients (or possible [D]DoS). But tonight for a short period of time one of the relays was running a bit "hot" so to say. Only to be greated by this log entry: Feb 12 18:54:55 tornode2 Tor[6362]: We're low on memory (cell queues total alloc: 1602579792 buffer total alloc: 1388544, tor compress total alloc: 1586784 rendezvous cache total alloc: 489909). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.) Feb 12 18:54:56 tornode2 Tor[6362]: Removed 1599323088 bytes by killing 1 circuits; 39546 circuits remain alive. Also killed 0 non-linked directory connections. Feb 12 19:04:10 tornode2 Tor[6362]: Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes. So 1 Circuit being able to claim 1,5 gig or ram, now this seems a big much. Whilst the DoS protection seems to do something (see below). Now this could be a new attack or just an error etc. However wouldn't some sort of fair memory balance between circuits be an other mitigation factor to consider? Not saying it should be as strict as "circuit memory"/"# of circuits" but 99.x% of memory for one circuit feels wrong for a relay. Feb 12 13:58:34 tornode2 Tor[6362]: DoS mitigation since startup: 910770 circuits rejected, 10 marked addresses. 25972 connections closed. 324 single hop clients refused. Feb 12 19:58:34 tornode2 Tor[6362]: DoS mitigation since startup: 1222320 circuits rejected, 12 marked addresses. 33359 connections closed. 402 single hop clients refused. Thx, Stijn

3 5

torservers are not rechable
by TorGate 11 Feb '18

11 Feb '18

Hi to all, i have started my servers again and changed the wan ip adress. But the servers have the old ip after uptime of 2 times. Can i update manualy the wan ips ? The dns names are changed to the new ipadresses. regards Steffen TorGate torgate(at)linux-hus.dk

3 3

Exits lost their function
by Paul 11 Feb '18

11 Feb '18

What could bring several exits at different providers and different operating systems (Linux and FreeBSD) down on the same day, Jan 21st? Since, while they still run as relays, they don’t show as exits any more without any change from my side. They do run on Tor 0.3.1.9 or 0.3.2.9 in the same Family. Thanks Paul

5 14

new requirements for Tor Exit relays in effect as of 2018-01-20
by nusenu 11 Feb '18

11 Feb '18

Dear Tor Exit Operator, I'm sending you this email to inform you that on 2018-01-20 the requirements for exit operators changed. Since that date your exit policy MUST allow exiting to port 80 _and_ 443 to be eligible for the exit flag. If your exit policy does not meet these new requirements, you lost your exit flag on 2018-01-20 (if you used to have it before that date). Find below a list of 34 exit relays that are affected by these requirement changes (consensus data as of 2018-01-19 13:00): contactInfo: 022F 0FF2 CB04 2342 7178 334F BA3F 9725 266C DD10 (OstwaldRipening) contactInfo: 0x49FAB046 Chris Jeane <chris jeane AT gmail dot com> (SpikeNJ) contactInfo: 0xB4F409D25BC71927 18NkcxXvFQKo2qyTqa6sQNt6bNEgXAvF9U (anoncat1) contactInfo: 0xd3956a77 Your pure Manifestation of Peace (newton) contactInfo: 0xFDB8716D Gerald Turner <gturner(a)unzane.com> - 1FRMLK42AvHNwn2NV3ASrxdMDYd12C1qbs (Unzane) contactInfo: 1024R/0FCE8549 Alexander Oelzant <alexander(a)oelzant.priv.at> (SCggHJTyWbtzDA9YZi) contactInfo: 145tXZyQEfdmpYhmbFtYe84kjghB5ymPA4 (NormalCitizen) contactInfo: 145tXZyQEfdmpYhmbFtYe84kjghB5ymPA4 (OrdinaryCitizen) contactInfo: 145tXZyQEfdmpYhmbFtYe84kjghB5ymPA4 (RegularCitizen) contactInfo: <admin AT openbsd DOT se> (che) contactInfo: Eran Sandler <eran(a)sandler.co.il> (tor4thepeople2) contactInfo: flo(a)gmx.it (DannenTor) contactInfo: Magnus <magnus(a)1337.cf> (Pandora) contactInfo: nobody AT example dot com (blent) contactInfo: Piotr <unknown(a)yahoo.com> (icubdw2o2xipsdc) contactInfo: replace k with c : kontakt @ zwiebeltoralf . de (zwiebeltoralf) contactInfo: replace k with c : kontakt @ zwiebeltoralf . de (zwiebeltoralf2) contactInfo: Systems Manager <service(a)ns.sol.net> (soltor0) contactInfo: Thor Exit <thor.exit AT yandex dot com> (ThorExit) contactInfo: torinternetzforall(a)aol.com (jUsTwAnTaFREEsHiRt) contactInfo: tor-mngr AT scalaire DOT fr (servicePublic2) contactInfo: Tsen <tsenchi.ng AT yandex dot com> (mycontribution) contactInfo: TvdW <tor AT tvdw DOT eu> - bitcoin 1NKKoCQwKs67eKBGedMD8wYoAs3Z4mMAex (EmpokNor) contactInfo: TvdW <tor AT tvdw DOT eu> - bitcoin 1NKKoCQwKs67eKBGedMD8wYoAs3Z4mMAex (TerokNor) contactInfo: VolkerWilcken at web dot de (EXITNODESAVE) contactInfo: yv3r3nd5yi1k(a)mail.ru (relay651054) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (alsaceonion) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (alsaceonionb) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (mandela) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (mandelab) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (montrealonion) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (montrealonionb) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (quebeconion) contactInfo: <zwiebeln at online de> please donate BTC 1K38x9xqK3YDzjehYFAEPzsESEC4ScH5wJ (quebeconionb) @niftybunny: I you are motivated, you can send them an email directly by extracting valid email data from this list. zwiebeln at online de, zwiebeltoralf and TvdW are aware, I don't know about the rest, and I obviously omitted those for which we do not have any contactInfo. The actual learning here are: Missing proper per-notifications for exit operators. This topic (new req: 80+443) has been discussed before [1] but has not been properly announced, this could have been a TPO tweet or a blog post or an email to this list with proper subject and not hidden in a long thread. I should auto-detect such events (multiple relays loosing flags at the same time) without knowing about them. [1] https://lists.torproject.org/pipermail/tor-relays/2017-December/013663.html https://lists.torproject.org/pipermail/tor-relays/2018-January/014278.html -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Question regarding exit sizing
by Conrad Rockenhaus 10 Feb '18

10 Feb '18

Hello, I have a question regarding relay sizing to add additional nodes to the network. What scenario is better for the network - adding five 100mbps nodes, or one 500 mbps node? Let’s keep it easy and say all five of those 100 mbps nodes would be in the same datacenter, configured in the same configuration, etc. I’m just curious, because I”m getting ready to add a few more nodes, but I’m wondering if it’ll be better to go big, or just stay small. Thanks, Conrad Rockenhaus

3 3