Re: [tor-relays] Exit Concentration vs Bulk filters?
> So what can we do to achieve the ideal distributed network? > Throttle all (nodes) to the slowest... to get the best diversity? > We need all (nodes), whether high or small capacity. Don't we? Tor is a form of gravity well. If the cloud is not saturated, adding more nodes increases odds of traffic analysis. Among other things, tor's utilization falloff curve should probably not give many users and use cases much comfy feels. Tor's design doesn't provide a way to distributively utilize excess nodes safely, it cannot, so it tries to game and manage that as best it can. Such global throttle could help, but access to throughput will disappear, and it's still subject to same class of analysis. Tor's design can't really do much here while still being called tor. Look elsewhere for other designs. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor crash on HUP only when SANDBOX is 1
Hi, This doesn't look like 32841 to me. The crash appears to be caused by a call to dup() newly added in 0.4.2.x [1]. I'm having trouble reproducing the issue though. The code appears to handle log output. Do you have any custom 'Log' configurations in your torrc? Regards Peter [1]: https://gitweb.torproject.org/tor.git/commit/?id=a22fbab98690f802ae3bda276078cc7fc767feba Roger Dingledine: > On Sun, Jan 05, 2020 at 08:18:53AM +0100, tor-re...@riseup.net wrote: >> just a little update: >> >> I've reproduced this bug on my laptop with Debian Buster. >> >> I've noticed that this problem occurs only with tor 0.4.2.5. Tor 0.4.1.6, >> from Debian buster backports repository, works properly. > > Hi! Yes, this is ticket > https://bugs.torproject.org/32841 > > I am hoping that when folks get back from their holidays, this will be > one of the tickets they get to quickly. > > Thanks, > --Roger > > ___ > 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
Re: [tor-relays] tor crash on HUP only when SANDBOX is 1
On 1/5/20 7:43 AM, tor-re...@riseup.net wrote: > Hi, > > I'm running an exit relay on a Debian Buster. I installed libseccomp and > I've built tor 0.4.2.5 using debuild, like the wiki says. > > Today I noticed that tor crashes on HUP signal, only when the Sandbox > option is on. I never had this problem. > maybe https://trac.torproject.org/projects/tor/ticket/29819 ? -- Toralf signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor crash on HUP only when SANDBOX is 1
On Sun, Jan 05, 2020 at 08:18:53AM +0100, tor-re...@riseup.net wrote: > just a little update: > > I've reproduced this bug on my laptop with Debian Buster. > > I've noticed that this problem occurs only with tor 0.4.2.5. Tor 0.4.1.6, > from Debian buster backports repository, works properly. Hi! Yes, this is ticket https://bugs.torproject.org/32841 I am hoping that when folks get back from their holidays, this will be one of the tickets they get to quickly. Thanks, --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor crash on HUP only when SANDBOX is 1
just a little update: I've reproduced this bug on my laptop with Debian Buster. I've noticed that this problem occurs only with tor 0.4.2.5. Tor 0.4.1.6, from Debian buster backports repository, works properly. Il 05/01/20 07:43, tor-re...@riseup.net ha scritto: Hi, I'm running an exit relay on a Debian Buster. I installed libseccomp and I've built tor 0.4.2.5 using debuild, like the wiki says. Today I noticed that tor crashes on HUP signal, only when the Sandbox option is on. I never had this problem. This is what my log says: an 05 08:23:10.000 [notice] Received reload signal (hup). Reloading config and resetting internal state. Jan 05 08:23:10.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Jan 05 08:23:10.000 [notice] Read configuration file "/etc/tor/torrc". Jan 05 08:23:10.000 [notice] Tor 0.4.2.5 opening log file. T= 1578205390 (Sandbox) Caught a bad syscall attempt (syscall dup) /usr/bin/tor(+0x1fc9fa)[0x561d896b29fa] /lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f0bebf4bbc7] /lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f0bebf4bbc7] /usr/bin/tor(tor_log_update_sigsafe_err_fds+0x18b)[0x561d896c699b] /usr/bin/tor(set_options+0x3c0)[0x561d89642f80] /usr/bin/tor(options_init_from_string+0x17d)[0x561d896453dd] /usr/bin/tor(options_init_from_torrc+0x404)[0x561d89645a74] /usr/bin/tor(+0x5f961)[0x561d89515961] /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22a6c)[0x7f0bec5a3a6c] /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)[0x7f0bec5a4537] /usr/bin/tor(do_main_loop+0xff)[0x561d8952a3af] /usr/bin/tor(tor_run_main+0x1105)[0x561d89517d55] /usr/bin/tor(tor_main+0x3a)[0x561d8951523a] /usr/bin/tor(main+0x19)[0x561d89514df9] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f0bebe8509b] /usr/bin/tor(_start+0x2a)[0x561d89514e4a] I'm telling you because i think it could be a bug, but I'm not sure that It's not caused by something else. At the moment I've disabled Sandbox. Please, let me know if I can fix this in some way, thanks. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit Concentration vs Bulk filters?
Such a clear explanation would be good to see on torproject.org. -Original Message-From: nusenu-li...@riseup.netSent: Sat, 04 Jan 2020 11:44:00 +To: tor-relays@lists.torproject.orgSubject: Re: [tor-relays] Exit Concentration vs Bulk filters?> I never heard a real technical reason to avoid> high concentration of Tor exit capacity. Let me give you a few examples why a distributed network is in some waysmore resilient to attacks and harder to observe than a centralized.ObservabilityIf all traffic leaves the tor network at a single or very few places, surveillance becomes a lot easier and cheaperwhen compared to a network that is distributed and has many exit locations.Resiliency against outagesIf all capacity is concentrated around just a few locations, local issues/outages have a bigger impacton the overall availability and capacity of the network.Resiliency against software vulnerabilitiesA single operator tends to setup their systems in a relatively similar manner.Most of its relays will use the same OS, OS version, SSL library, tor version, hardware architectureand have a similar good or bad patch level.In such an environment it is more likely that a single vulnerability affects large portions when comparedto a diverse ecosystem. A homogeneous ecosystem also reduces the cost for exploit development.Resiliency against security breachesIf an hypothetical operator controlling 1/2 of the network gets compromised the impact is a lot bigger thanif they were to run 1%. The incentive for an attacker to compromise an operator running 50%of the network is also a lot higher than attacking an operator of 1%.Risk of detectionThe risk of detection is likely higher for an attacker that compromises multiple organizations compared to a singlevictim.Cost of attacksCompromising all relays operated by a single entity is likely cheaper than compromising all relaysrun by multiple independent organizations.Performing a hijacking attack against a single prefix is probably easier than successfully hijacking multiple independentprefixes with different upstream providers concurrently and harder to remain undetected.A DDoS attack against a single AS is likely cheaper than against many targets at the same time.There are also non-technical (organizational and legal) reasons why having a distributed network capacity is beneficial to the tor network.Legally attacking many organizations is more expensive than a single one.If a single operator no longer has the financial capacity or motivation the removal of their relays should nothave a existential impact on the network.If the policy of a hoster changes from 'tor relays allowed' to 'tor relays forbidden'than we better not run all our capacity at a single hoster.In short, you don't want to make the tor network depend on 1-2 or 10 but many.So if a few operators disappear the network remains functional and availableand is generally harder to attack.kind regards,nusenu-- https://mastodon.social/@nusenuhttps://twitter.com/nusenu ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] tor crash on HUP only when SANDBOX is 1
Hi, I'm running an exit relay on a Debian Buster. I installed libseccomp and I've built tor 0.4.2.5 using debuild, like the wiki says. Today I noticed that tor crashes on HUP signal, only when the Sandbox option is on. I never had this problem. This is what my log says: an 05 08:23:10.000 [notice] Received reload signal (hup). Reloading config and resetting internal state. Jan 05 08:23:10.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Jan 05 08:23:10.000 [notice] Read configuration file "/etc/tor/torrc". Jan 05 08:23:10.000 [notice] Tor 0.4.2.5 opening log file. T= 1578205390 (Sandbox) Caught a bad syscall attempt (syscall dup) /usr/bin/tor(+0x1fc9fa)[0x561d896b29fa] /lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f0bebf4bbc7] /lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f0bebf4bbc7] /usr/bin/tor(tor_log_update_sigsafe_err_fds+0x18b)[0x561d896c699b] /usr/bin/tor(set_options+0x3c0)[0x561d89642f80] /usr/bin/tor(options_init_from_string+0x17d)[0x561d896453dd] /usr/bin/tor(options_init_from_torrc+0x404)[0x561d89645a74] /usr/bin/tor(+0x5f961)[0x561d89515961] /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22a6c)[0x7f0bec5a3a6c] /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)[0x7f0bec5a4537] /usr/bin/tor(do_main_loop+0xff)[0x561d8952a3af] /usr/bin/tor(tor_run_main+0x1105)[0x561d89517d55] /usr/bin/tor(tor_main+0x3a)[0x561d8951523a] /usr/bin/tor(main+0x19)[0x561d89514df9] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f0bebe8509b] /usr/bin/tor(_start+0x2a)[0x561d89514e4a] I'm telling you because i think it could be a bug, but I'm not sure that It's not caused by something else. At the moment I've disabled Sandbox. Please, let me know if I can fix this in some way, thanks. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bwauths don't like one of my relays?
An update on my relay 'kima' ($54A35E582F9E178542ECCFA48DBE14F401729969) -- Eventually I did get assigned more weight; the relay is currently at 4600. Along the way I think I discovered one potential problem with the bwauth bootstrapping process, at least for sbws. (I'm not sure about torflow.) When sbws is constructing a two-hop measurement circuit to run a test, it tries to pick an exit that has at least twice the consensus weight of the current relay-under-test: https://github.com/torproject/sbws/blob/master/sbws/core/scanner.py#L216 So this means that in this case, sbws would have picked any exit that was not a BadExit, has an acceptable ExitPolicy, and has a consensus weight of at least, well, 2. That's not a lot. As it turns out, something like 10% of exits have under a 600Kbyte/sec advertised bandwidth. So it seems pretty easy from this weight=1 bootstrap scenario to get paired with an exit that will give poor test results. Perhaps bwauth path selection should also choose a testing pair from exits/relays with a certain absolute minimum of weight or advertised bandwidth? Best, -Jimmy___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
