- tor-dev - lists.torproject.org

Self coded GUI for Tor Windows Relay Software
by Keifer Bly 21 Dec '20

21 Dec '20

Hi Tor Developers, This is a project I have been working on which allows users to run relays on Windows with ease. Made this for volunteers who want to run relays, but only have Windows. See here https://www.youtube.com/watch?v=Vpk6yvUWQqU Features: Easy configuring of tor Auto installation of tor or upgrade to newest version at launch Start relay when OS starts Keep tor software up to date automatically Drawbacks: Only supports vanilla bridges currently. Configures Windows Firewall to allow relay traffic automatically, but can’t auto configure any other firewalls. Tested and working. I saw a video saying tor could use more Windows developers, so I developed this. I am happy to send the source code if you wish. Would be cool to have this published on tor project website under OS instructions for running relays. --Keifer

1 0

Debian signing keys
by enrollado 21 Dec '20

21 Dec '20

I'm getting invalid signing key messages on the Debian Buster repos. Has something changed? Sent with ProtonMail Secure Email.

1 0

ARTI
by Zaphoid 12 Dec '20

12 Dec '20

Greetings Tor-Dev, I've watched Nick's presentation on State of the Onion and have read the "Tor in 2021" blog post searching for more details on A Rust Tor Implementation (ARTI). I think Rust is a fascinating language and looking to further my knowledge of it and Tor's internals as they are developed. I understand that some Rust implementation is available in the source repository. What I am looking for is a road-map or planned outcome. Could anyone advise if the intent is to completely re-write the Tor client in Rust? Or, is the project's goal to rewrite specific components? Z

2 1

My app which makes running tor relays on Windows Very Simple
by Keifer Bly 12 Dec '20

12 Dec '20

Hi all, So this is a software peice I have been developing which makes running tor relays on Windows very easy. All the user needs to do is write their torrc. The app installs tor, and configures all once the torrc is written by itself. Here is a video showing the app: Features Automatic Tor download and installation (via Choclatey) Type the torrc file, and the app configures and points tor there for you. Attempted automatic firewall configuration. Automatic creation of log file. Cons: Currently only directly support vanilla bridges. OBFS4 will have to be manually downloaded / configured. ATTEMPTED firewall auto configuration. It auto adds a rule to Windows Defender Firewall to allow the traffic, but can't configure router firewalls, etc. Let know what you think. I have successfully gotten tor up and running through this. If chocolatey changes their install scripts, this will need to be updated. I can send the source code if interested. Programming Language: C#/.Net Tor Windows App.mp4 <https://drive.google.com/file/d/1ZJ4EKXbu2Clyzc5WdNdxSWquswhdvSTJ/view?usp=…> --Keifer

1 0

Trouble with onionperf visualize and S61 performance experiments
by George Kadianakis 07 Dec '20

07 Dec '20

Hello Karsten, hope you are doing well! I've been working on the S61 performance experiments [0] and I would appreciate some help with onionperf. I have done various onionperf measurements using something the following command: $ onionperf measure -i --tgen ~/tgen/build/src/tgen --tor ~/onionperf/tor/src/app/tor --drop-guards 10 I put each of the measurements on a different directory and now I want to analyze them and derive the CDF-TTFB graphs etc. I attempted doing that using the following calls: $ onionperf analyze --tgen ./tgen-client/onionperf.tgen.log --torctl ./tor-client/onionperf.torctl.log $ onionperf visualize --data onionperf.analysis.json.xz "test" Unfortunately, the 'visualize' call can fail for the attached 'onionperf-mbps.json.xz': $ onionperf visualize --data onionperf.analysis.json.xz "Test Measurements" 2020-11-03 15:51:31 1604411491.540736 [onionperf] [INFO] loading analysis results from /user/tmp/onionperf/analysis/onionperf.analysis.json.xz 2020-11-03 15:51:31 1604411491.577864 [onionperf] [INFO] done! 2020-11-03 15:51:31 1604411491.586845 [onionperf] [INFO] NumExpr defaulting to 8 threads. /user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/onionperf/visualization.py:251: UserWarning: Attempting to set identical left == right == -1e-06 results in singular transformations; automatically expanding. /user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/onionperf/visualization.py:251: UserWarning: Attempting to set identical left == right == -1e-06 results in singular transformations; automatically expanding. Traceback (most recent call last): File "/user/.local/bin/onionperf", line 4, in <module> __import__('pkg_resources').run_script('OnionPerf==0.8', 'onionperf') File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 650, in run_script self.require(requires)[0].run_script(script_name, ns) File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1453, in run_script exec(script_code, namespace, namespace) File "/user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/EGG-INFO/scripts/onionperf", line 622, in <module> File "/user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/EGG-INFO/scripts/onionperf", line 382, in main File "/user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/EGG-INFO/scripts/onionperf", line 522, in visualize File "/user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/onionperf/visualization.py", line 48, in plot_all File "/user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/onionperf/visualization.py", line 205, in __plot_throughput_ecdf File "/user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/onionperf/visualization.py", line 235, in __draw_ecdf File "/usr/lib/python3/dist-packages/pandas/core/frame.py", line 5000, in dropna raise KeyError(list(np.compress(check, subset))) KeyError: ['mbps'] Then for another onionperf run (attached as 'onionperf-44028.json.xz') it gave me a different error: $ onionperf visualize --data onionperf.analysis.json.xz "Test Measurements" 2020-11-03 15:50:03 1604411403.946028 [onionperf] [INFO] loading analysis results from /user/tmp/onionperf/analysis/onionperf.analysis.json.xz 2020-11-03 15:50:03 1604411403.976088 [onionperf] [INFO] done! Traceback (most recent call last): File "/user/.local/bin/onionperf", line 4, in <module> __import__('pkg_resources').run_script('OnionPerf==0.8', 'onionperf') File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 650, in run_script self.require(requires)[0].run_script(script_name, ns) File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1453, in run_script exec(script_code, namespace, namespace) File "/user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/EGG-INFO/scripts/onionperf", line 622, in <module> File "/user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/EGG-INFO/scripts/onionperf", line 382, in main File "/user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/EGG-INFO/scripts/onionperf", line 522, in visualize File "/user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/onionperf/visualization.py", line 38, in plot_all File "/user/.local/lib/python3.8/site-packages/OnionPerf-0.8-py3.8.egg/onionperf/visualization.py", line 129, in __extract_data_frame KeyError: '44028' Because of the two errors above I'm unable to proceed with producing any results. Any idea what I might be doing wrong? Is there any other data you might need to help me with this? Thanks a lot! [0]: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor/Performa… https://gitlab.torproject.org/tpo/core/tor/-/issues/40157

2 6

Resolving TXT records
by Jorropo 27 Nov '20

27 Nov '20

Hi, I'm trying to port go-libp2p <https://libp2p.io/> on tor. The problem is with the dnslink features. Basically libp2p addresses are not always friendly to use so libp2p allows to store them in dns TXT records. But when I try to resolve a TXT record over Tor this errors : tor --DNSPort 127.53.53.53 & host -v -t any jorropo.net Trying "jorropo.net" ;; Connection to 127.53.53.53#53(127.53.53.53) for jorropo.net failed: connection refused. # I'm pretty confident the dns option of Tor is working because I can resolve A records. Is this expected or I am doing something wrong?

2 1

Tor Browser 10.0.5 not functional on Fedora Rawhide
by Ian Laurie 24 Nov '20

24 Nov '20

Regular Firefox became briefly non-functional on Fedora Rawhide due to the following (now resolved) bug: https://bugzilla.redhat.com/show_bug.cgi?id=1891234 The issue was that all tabs immediately crashed making the browser unusable. I believe Tor is now suffering from the same issue. -- Ian Laurie

2 1

tor relay process health data for operators (controlport)
by nusenu 16 Nov '20

16 Nov '20

Hi, every now and then I'm in contact with relay operators about the "health" of their relays. Following these 1:1 discussions and the discussion on tor-relays@ I'd like to rise two issues with you (the developers) with the goal to help improve relay operations and end user experience in the long term: 1) DNS (exits only) 2) tor relay health data 1) DNS ------ Current situation: Arthur Edelstein provides public measurements to tor exit relay operators via his page at: https://arthuredelstein.net/exits/ This page is updated once daily. the process to use that data looks like this: - first they watch Arthur's measurement results - if their failure rate is non-zero they try to tweak/improve/change their setup - wait for another 24 hours (next measurement) This is a somewhat suboptimal and slow feedback loop and is probably also less accurate and less valuable data when compared to the data the tor process can provide. Suggestion for improvement: Exposes the following DNS status information via tor's controlport to help debug and detect DNS issues on exit relays: (total numbers since startup) - amount of DNS queries send to the resolver - amount of DNS queries send to the resolver due to a RESOLVE request - DNS queries send to resolver due to a reverse RESOLVE request - amount of queries that did not result in any answer from the resolver - breakdown of number of responses by response code (RCODE) https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-pa… - max amount of DNS queries send per curcuit If this causes a significant performance impact this feature should be disabled by default. 2) general relay health metrics -------------------------------- Compared to other server daemons (webserver, DNS server, ..) tor provides little data for operators to detect operational issues and anomalies. I'd suggest to provide the following stats via the control port: (most of them are already written to logfiles by default but not accessible via the controlport as far as I've seen) - total amount of memory used by the tor process - amount of currently open circuits - circuit handshake stats (TAP / NTor) DoS mitigation stats - amount of circuits killed with too many cells - amount of circuits rejected - marked addresses - amount of connections closed - amount of single hop clients refused - amount of closed/failed circuits broken down by their reason value https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1402 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1994 - amount of closed/failed OR connections broken down by their reason value https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2205 If this causes a significant performance impact this feature should be disabled by default. cell stats - extra info cell stats as defined in: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1072 This data should be useful to answer the following questions: - High level questions: Is the tor relay healthy? - is it hitting any resource limits? - is the tor process under unusual load? - why is tor using more memory? - is it slower than usual at handling circuits? - can the DNS resolver handle the amount of DNS queries tor is sending it? This data could help prevent errors from occurring or provide additional data when trying to narrow down issues. When it comes to the question: **Is it "safe" to make this data accessible via the controlport?** I assume it is safe for all information that current versions of tor writes to logfiles or even publishes as part of its extra info descriptor. Should tor provide this or similar data I'm planing to write scripts for operators to make use of that data (for example a munin plugin that connects to tor's controlport). I'm happy to help write updates for control-spec should these features seem reasonable to you. Looking forward to hearing your feedback. nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

5 7

Statistical inference in live network perf experiments
by Jansen, Robert G CIV USN NRL (5543) Washington DC (USA) 18 Oct '20

18 Oct '20

Hello Mike and David! I see that we are in the process of testing some changes to KIST parameters, and have more upcoming perf experiments planned. It will be great to gather additional information to help us better understand how to improve Tor performance :) My main concern about running experiments on the live network is the lack of control [0] across the uncountable number of confounding variables present across the network. Because of the lack of control, I strongly advise that statistical inference techniques are applied when conducting the experiments and analyzing the results. Ideally you will estimate and quantify sources of systematic error. Repeated trials and A/B testing (when that makes sense) will help increase our confidence in your results. We have some recent work on these topics (in submission). DM if you are interested in a copy of the paper. Peace, love, and positivity, Rob [0] https://en.wikipedia.org/wiki/Scientific_control

1 1

Improving Tor network models [was: Update to Proposal 316: FlashFlow]
by Jansen, Robert G CIV USN NRL (5543) Washington DC (USA) 17 Oct '20

17 Oct '20

> > On Oct 8, 2020, at 2:50 PM, Mike Perry <mikeperry(a)torproject.org> wrote: > > I do not yet have confidence that these issues are solved simply because > they did not appear in Shadow. Shadow does not simulate multi-instance > relays, CPU bound relays, or structural load imbalances in the network. Hi Mike and others! I'd like to better understand your criticisms here so that we can work to make Shadow more useful (work that fits squarely under sponsor 38). > multi-instance relays Nothing prevents Shadow from running multiple tor relay processes on the same virtual host. We could add this to the Tor models that are created by our model generation tool[0]. One issue is that we don't have ground truth about: - which relays are co-resident with one another; and - the capacity of the machine hosting the co-resident relays. A short term fix could be that we look at relays in the same family, and randomly choose some of them to run on the same machine (setting the capacity of the machine as the sum of max observed bandwidth of the co-resident relays). A longer term solution would be to add a new parameter similar to MyFamily and ask operators to identify which relays are co-resident, or add to tor a self-measurement of co-residency - and that would provide the ground truth we would need for accurate modeling. Thoughts? Any other ideas? > CPU-bound relays There are two issues here: - we need to improve/rewrite our virtual CPU module in Shadow that accounts for CPU load; and - we need ground truth about the number of CPUs and CPU speeds for each relay. The first one is relatively straightforward to resolve, the second one again requires some form of self-reporting or automated self-measurement in tor. > structural load imbalances Could you please explain this one in a couple more sentences? By 'structural' I think you might mean imbalances across relay positions (i.e., more guard bandwidth and less exit bandwidth). If so, then Shadow does already properly account for this by statically assigning flags using the TestingDirAuthVoteExit and TestingDirAuthVoteGuard torrc options. Here are some bonus ones for you: > capacity of relays We currently use the maximum observed bandwidth that we've seen for a relay and set that value as the network link capacity of the (virtual) host machine that runs reach relay. Again, we don't have any ground truth of how much capacity is available to each relay, though maybe someday FlashFlow will collect it for us. > diversity of Tor versions We should make sure our modeling tool includes relays across different versions of Tor, since not all relays in the public network run the same version. This one is pretty simple to fix (it just requires us to build Tor plugins multiple different Tor source versions) but research that is testing how a new idea performs across the network by modifying Tor source will obviously need to use their custom research version of Tor. Peace, love, and positivity, Rob [0] https://github.com/shadow/tornetgen

1 0