Re: [tor-dev] Grailo.net is live (but very young)
On 01/12/12 23:39, Clay Graham wrote: > You may remember an email from me about a week ago, and I could really > use some pointers. > > We just stealth launched an alpha version of http://grailo.net and I > would love all of you to try it out and give me feedback. Its 100% open > source, 100% free, and you can even fork the project yourself on github. > > Its goal: Create a simple to use client side, RSA public key encryption > for microblogging on the internet. > > The reason I am reaching out to you is I am I am interested in creating > a client side plugin for the TOR browser so that people can use the > client side encryption safely and privately, and without fear. Since > scripting is disabled in TOR, with good reason, I want a plugin that is > blessed by the TOR project as open and safe for encryption. > > Any leads on where to get started are greatly appreciated. I can't trust any javascript that your service sends to my browser over Tor, because you don't use https. That javascript on the signup page which generates your private key... How do I know that script came from your server and that it's not a modified version which came from an exit node, which is going to report the key back to them after it is generated? At a bare minimum, before I would even start considering using this service, every single resource that your site delivers should be sent over https, all http connections should be redirected to https. HSTS should be used so browsers remember to use https, and you should contact the Chromium project to get yourself on their list of pinned SSL sites for first time visitors (which is also used in Firefox now I believe), and is also used in the HTTPS-Everywhere project for rule generation. -- Mike Cardwell https://grepular.com/ http://cardwellit.com/ OpenPGP Key35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 signature.asc Description: OpenPGP digital signature _______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] InjectSOCKS
___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] InjectSOCKS: 2nd try
Hello, I've first sent this e-mail to h...@rt.torproject.org and the answer was to send a copy of it to the "tor-dev mailing list". So that's what I do: I just wanted to let you know that I've created a small new tool for Windows called InjectSOCKS that can force other Windows software to do TCP connections via SOCKS. This way software not supporting SOCKS can be used together with Tor. You don't need any additional HTTP proxy or other proxies. As an example it works for passive FTP, too. Additionally it handles the DNS requests of that other software in a way that while creating the SOCKS connection, Tor gets the textual address - so the exit node can resolve it (which is the way favored by the Tor developers). This way Tor hidden services work as well. And it works per Windows process, so it doesn't influence the whole operating system. In case you're interested in my software, I've put it on sourceforge to make it open source: http://sourceforge.net/projects/injectsocks The tool is far from being perfect yet, but I think some of the ideas are interesting. By the way, I've also created DNS2SOCKS, which is already listed on Tor's Wiki: http://sourceforge.net/projects/dns2socks It seems like several people like it, so I hope that some people will also like InjectSOCKS. Regards, ghostmaker _______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] InjectSOCKS: 2nd try
Hello Nick, thank you very much for the fast response. > Assuming that you didn't use anybody else's code to write it, you > can pick any open source license that you'd like That's a good advice. I've set the BSD license in sourceforge for both tools now. You can see it on the summary page. On the next updates I'll put the license text also into the ReadMe.txt files. I have to do some more testing on InjectSOCKS with different network tools - I've mainly used the well known browsers so far for testing. On some tools it still fails (e.g. Internet Explorer only works partly) - but it's at least a proof of concept :-) Regards, ghostmaker ___________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] InjectSOCKS: 2nd try
Hello David, thank you for your reaction. I've read some information about "Torsocks" now and yes, it seems to be similar. Unfortunately the information on Torsocks's homepage is rather short. So I can't tell you if the internal technology is similar. It tells that it explicitly rejects UDP traffic. It would be possible to block UDP traffic in InjectSOCKS as well. By the way, why does Tor not support UDP via SOCKS? The Torsocks documents also say that it blocks local traffic as well. While implementing InjectsSOCKS I saw that some Windows software needs local traffic in order to work for internal inter process communication (maybe Internet Explorer - not sure anymore). So I've explicitly prevented using the SOCKS server for local traffic (wouldn't make sense) and don't reject it - otherwise this software wouldn't work anymore. > Do you think you can put your code into a git repository (github, > gitourious, ...). That would be *very* helpful to review/contribute > and track changes. Unfortunately I'm not familiar with git. However, the source code is rather small. The most important parts are in InjectSOCKS_DLL.c The sources are already commented a little bit, but I think that I'll add Visual C++ XML or doxygen style documentation. This way it's easier to understand and review/analyze the code. For the moment I'd like to suggest sending me any change suggestions or questions via e-mail. If we detect that this is not manageable, we can still switch to a different solution. By the way, I've released V1.1 of InjectSOCKS now. This adds the BSD license text and a dialog for creating a Windows shortcut file to call InjectSOCKS correctly. The dialog pops up when you start InjectSOCKS without any parameter. This helps users not familiar with the command line. Known bug: There is a small possible memory leak in the function "CreateLink" of that dialog; it will be fixed in the next release :-) Regards, ghostmaker ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] InjectSOCKS: 2nd try
Hello David, > Yes, UDP is simply not supported by Tor thus it will be rejected > when opening the socket. Actually, it's not only UDP that should be > blocked but *every* other protocol except TCP. For instance, there > is no way to send icmp request through Tor thus we don't want that > to leak. ... > This is dangerous and the reason why it's denied is that the > application could easily make a DNS request for instance to a > local server that will then resolve it on a remote one thus > leaking. > > You should really reconsider that, going locally can be fine but > also really dangerous. Thanks for all the advice. I've uploaded a new version now where the default behavior is to block any other sockets than TCP sockets and to block 127.x.x.x traffic. However, there is the optional switch /a to allow this as some software just needs it, e.g. Internet Explorer uses local UDP traffic to communicate between its processes. So the user can decide per process which mode to use. The new version also has some additional tweaks and fixes. Concerning the upper "security" feature I think that everybody using a software like InjectSOCKS should be aware that there are a lot of ways to bypass all this. You shouldn't rely on it. The goal of InjectSOCKS is to use software together with Tor (or other SOCKS servers) even if it doesn't support this. Creating a sandbox or disabling malware is not the goal of InjectSOCKS. There are other tools for that and it's a good idea to have a firewall preventing any "bad" traffic. Well, at least it's a proof of concept that you can manipulate the process behavior using this technique :-) > I'll take a look at it and if I can find a Windows, test it. If you just want to test it you could use the official Microsoft trial version running for 90 days or something like that. > From that point on, I'll check how feasible it is to integrate what > you did in the new torsocks code so we can have *nix and Windows > support in the same tool, that would be quite awesome. This sounds very interesting. My guess is that while the tools are similar, the internals are quite different. But this is just a guess :-) Thanks for the effort. Cheers ghostmaker _______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Tor Bridges and Snowflakes detection attack
Hi, https://github.com/scriptzteam/Tor-Bridges-Collector Seems an attacker has found a way to enumerate ~30 snowflakes and many bridges. I couldn't find any discussion about this in the archive. Thanks, OpenPGP_0x45E5F8C1504CDA42.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature _______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Bridges and Snowflakes detection attack
Any ideas how so many bridges have been discovered? While snowflakes are more trivial just by harvesting it from a client. My understanding is bridges should not be possible to easily enumerate, any network level attacker (Iran, ISP, Company) can just blocklist these nodes due to this github repo. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Looking for resources
Hello, I was going through the Tor proposals which have now been closed. I have been looking for discussion regarding those proposals (here - https://gitweb.torproject.org/torspec.git) Could you link me to some discussion threads because I couldn't find much on them? Thank you _______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Iran
On Sunday 05 May 2013 14:50:51 George Kadianakis wrote: > It would be interesting to learn which ports they currently whitelist, > except from the usual HTTP/HTTPS. > > I also wonder if they just block based on TCP port, or whether they > also have DPI heuristics. > > On the Tor side, it seems like we should start looking into #7875: > https://trac.torproject.org/projects/tor/ticket/7875 > ___ I am wondering if here is there a way for a user to ask bridgedb for a bridge with a specific port? ___________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Gitian Build Failure (pt branch only?)
On Thursday 12 December 2013 09:35:45 Kevin P Dyer wrote: > Hi Mike/dcf1, > > Building the pt branch [1] of tor-browser-bundle on Ubuntu 13.04, > 64-bit resulted in the following error: > Same error here with Ubuntu 12.04 64-bit. My system runs with the linux- image-generic (linux-image-3.2.0.57-generic) but I get the error. I was able to build tbb-30rc1-release before. Regards, torland _______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Gitian Build Failure (pt branch only?)
On Friday 13 December 2013 14:21:10 David Fifield wrote: > Do you have the same symptoms we experienced? That is, during the build > of tor for lucid-i386, you have a qemu process running with image > target-precise-amd64.qcow2? And if you ssh into the VM with > ssh -oNoHostAuthenticationForLocalhost=yes -i gitian- builder/var/id_dsa -p > 2223 root@localhost and then run "halt", the VM appears to shut down, but > the same qemu process keeps running? > > I think it's possible to have linux-image-generic package installed, but > not actually be running 3.2.0. What does "uname -a" say? > > David Fifield I restarted the make this morning but could no longer recreate the issue for Linux and Windows. There is another issue with Mac, but that is caused by an rsyn error. I still have the output from yesterdays make: ** Starting Tor Component of Linux Bundle (1/3 for Linux) ** --- Building tor-linux for lucid i386 --- Stopping target if it is up Making a new image copy Formatting 'target-lucid-i386.qcow2', fmt=qcow2 size=11811160064 backing_file='base-lucid-i386.qcow2' encryption=off cluster_size=65536 Starting target Checking if target is up Preparing build environment Updating apt-get repository (log in var/install.log) Installing additional packages (log in var/install.log) Grabbing package manifest Creating build script (var/build-script) Running build script (log in var/build.log) ./bin/gbuild:21:in `system!': failed to run on-target setarch i386 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError) from ./bin/gbuild:121:in `build_one_configuration' from ./bin/gbuild:223 from ./bin/gbuild:218:in `each' from ./bin/gbuild:218 from ./bin/gbuild:216:in `each' from ./bin/gbuild:216 make: *** [build] Error 1 >From that make there was also still a qemu process running: /bin/sh /home/user/make/gitian.builder/libexec/start-target 64 precises-amd64 qemu-system-x86_64 -enable-kvm -m 2000 -smp 2 -drive file=target-precise- amd64.qcow2,cache=writeback -net nic,model=virrio -net user,hostfwd=tcp:127.0.01:2223-:22 -vnc 127.0.0.1:16 I logged into it as you suggested and called halt. The ssh connection dropped, but the quemu process kept running: user@host:~$ ssh -oNoHostAuthenticationForLocalhost=yes -i ~/make/gitian- builder/var/id_dsa -p 2223 root@localhost Welcome to Ubuntu 12.04.3 LTS (GNU/Linux 3.2.0-57-virtual x86_64) * Documentation: https://help.ubuntu.com/ root@ubuntu:~# halt Broadcast message from root@ubuntu (/dev/pts/0) at 16:15 ... The system is going down for halt NOW! root@ubuntu:~# Connection to localhost closed by remote host. My uname output is: user@host:~$ uname -a Linux host 3.2.0-57-generic #87-Ubuntu SMP Tue Nov 12 21:35:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux cheers, torland _______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Gitian Build Failure (pt branch only?)
On Saturday 14 December 2013 19:26:41 Georg Koppen wrote: > > FWIW, this is probably https://trac.torproject.org/projects/tor/ticket/10153 > > Georg I am seeing the following error for the Mac bundle: ** Starting TorBrowser Component of Mac Bundle (2/3 for Mac) ** sha256sum: x86_64-apple-darwin10.tar.xz: No such file or directory --- Building torbrowser-mac for precise amd64 --- Stopping target if it is up Killing target since it did not shutdown within 10 seconds Making a new image copy Formatting 'target-precise-amd64.qcow2', fmt=qcow2 size=11811160064 backing_file='base-precise-amd64.qcow2' encryption=off cluster_size=65536 Starting target Checking if target is up. Preparing build environment rsync: link_stat "/home/user/make/gitian-builder/inputs/x86_64-apple- darwin10.tar.xz" failed: No such file or directory (2) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1070) [sender=3.0.9] ./bin/gbuild:21:in `system!': failed to run copy-to-target inputs/x86_64- apple-darwin10.tar.xz build/ (RuntimeError) from ./bin/gbuild:86:in `build_one_configuration' from ./bin/gbuild:84:in `each' from ./bin/gbuild:84:in `build_one_configuration' from ./bin/gbuild:223 from ./bin/gbuild:218:in `each' from ./bin/gbuild:218 from ./bin/gbuild:216:in `each' from ./bin/gbuild:216 make: *** [build] Error 1 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Gitian Build Failure (pt branch only?)
On Monday 16 December 2013 08:11:49 Georg Koppen wrote: > That is a different issue probably due to the new cross-compiler missing > in your gitian-builder/inputs directory. You need to run at least > > make prep-alpha > > before starting the build with > > make build-alpha > > Georg Thanks Georg. That resolved the error. ___________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Building tbb-4.0a1-build2 fails
Hi, when I try to build ttb-4 I run into an error on compiling openssl. I was able to compile previous versions of tbb. Any idea what I am missing for ttb-4? Thanks & regards, torland --- Building utils-linux for lucid i386 --- Stopping target if it is up Making a new image copy Formatting 'target-lucid-i386.qcow2', fmt=qcow2 size=11811160064 backing_file='base-lucid-i386.qcow2' encryption=off cluster_size=65536 Starting target Checking if target is up Preparing build environment Updating apt-get repository (log in var/install.log) Installing additional packages (log in var/install.log) Grabbing package manifest Creating build script (var/build-script) Running build script (log in var/build.log) ./bin/gbuild:21:in `system!': failed to run on-target setarch i386 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError) from ./bin/gbuild:122:in `build_one_configuration' from ./bin/gbuild:224 from ./bin/gbuild:219:in `each' from ./bin/gbuild:219 from ./bin/gbuild:217:in `each' from ./bin/gbuild:217 make: *** [build-alpha] Error 1 from ../../gitian-builder/var/build.log gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -DTERMIO -O3 -fomit- frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 - DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM - DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM - DGHASH_ASM -c -o x86cpuid.o x86cpuid.s x86cpuid.s: Assembler messages: x86cpuid.s:8: Error: invalid instruction suffix for `push' x86cpuid.s:9: Error: invalid instruction suffix for `push' x86cpuid.s:10: Error: invalid instruction suffix for `push' x86cpuid.s:11: Error: invalid instruction suffix for `push' x86cpuid.s:13: Error: invalid instruction suffix for `pushf' x86cpuid.s:14: Error: invalid instruction suffix for `pop' x86cpuid.s:17: Error: invalid instruction suffix for `push' x86cpuid.s:18: Error: invalid instruction suffix for `popf' x86cpuid.s:19: Error: invalid instruction suffix for `pushf' x86cpuid.s:20: Error: invalid instruction suffix for `pop' x86cpuid.s:130: Error: invalid instruction suffix for `pop' x86cpuid.s:131: Error: invalid instruction suffix for `pop' x86cpuid.s:132: Error: invalid instruction suffix for `pop' x86cpuid.s:133: Error: invalid instruction suffix for `pop' x86cpuid.s:145: Error: invalid instruction suffix for `pop' x86cpuid.s:147: Error: relocated field and relocation type differ in signedness x86cpuid.s:161: Error: invalid instruction suffix for `pop' x86cpuid.s:163: Error: relocated field and relocation type differ in signedness x86cpuid.s:169: Error: invalid instruction suffix for `pushf' x86cpuid.s:170: Error: invalid instruction suffix for `pop' x86cpuid.s:174: Error: invalid instruction suffix for `push' x86cpuid.s:175: Error: invalid instruction suffix for `push' x86cpuid.s:192: Error: invalid instruction suffix for `pushf' x86cpuid.s:193: Error: invalid instruction suffix for `pop' x86cpuid.s:223: Error: invalid instruction suffix for `pop' x86cpuid.s:225: Error: relocated field and relocation type differ in signedness x86cpuid.s:253: Error: invalid instruction suffix for `push' x86cpuid.s:262: Error: invalid instruction suffix for `pop' x86cpuid.s:270: Error: invalid instruction suffix for `push' x86cpuid.s:289: Error: invalid instruction suffix for `pop' ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Building tbb-4.0a1-build2 fails
On Wednesday 06 August 2014 05:04:48 David Fifield wrote: > You probably need to kill your qemu process and start "build-alpha" > again. See: > https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/BuildingWithGit > ian#AssemblyErrorsinMismatchedArchitectureCode Thanks David for pointing me to that document. Killing qemu resolved the issue. _______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposal 334: A flag to mark Relays as middle-only
David Goulet: > However, I'm not sure we should always let 1 authority dictate that flag > regardless of what the others think. > > I think we need to enforce majority here and not have one > single authority dictate it. > > Thoughts? > +1 I can compromise one authority and can MiddleOnly the whole Tor network. ___________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Problems. Flash plugin works by default! I can see youtube video with Tor Browser Bundle
Hi, I've installed Tor Browser Bundle for Windows (tor-browser-2.3.25-2_ru) I didn't change any settings. When I visit any html-page on which there is a flash video i can see it, flash works! Why? It must not work! In settings(plugins) "Flash plugin" is disabled and it is inactive. In Tor Button settings Plugins are turned off. What happens? Is it a BUG? Regards. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Problems. Flash plugin works by default! I can see youtube video with Tor Browser Bundle
This was a HTML5 video. Thank you All for answers. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Concerns regarding a multilingual version of TBB,
I saw an email on the Wiki mailing list concerning a multilingual version of Tor. If that was made possible your language tag be used to track you. This could break your anonymity. Your thoughts? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A Simple Web of Trust for Tor Relay Operator IDs
While I understand the rationale for proposals such as these and agree there is a problem with malicious relays on the network, I feel that proposals such as these: - Raise the barrier for entry. People that would like to contribute to the network by running a relay or several relays would have this extra administrative burden now - These extra verification steps and collected details nibble-away ones ability to contribute to the network anonymously. - Despite individuals' best intent, systems and processes for collection and aggregation of personal details often have vulnerabilities. These vulnerabilities, when exported could be used to harm the very people the project is designed to protect. Z Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, October 3rd, 2021 at 12:16 PM, nusenu wrote: > Hi, > > I wrote down a spec for a simple web of trust > > for relay operator IDs: > > https://gitlab.torproject.org/nusenu/torspec/-/blob/simple-wot-for-relay-operator-ids/proposals/ideas/xxx-simple-relay-operator-wot.md#a-simple-web-of-trust-for-tor-relay-operator-ids > > This is related to: > > https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40001 > > https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html > > kind regards, > > nusenu > ------- > > https://nusenu.github.io > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Client identification for authenticated onions
unsubscribe Regards, Shannon Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, December 7th, 2021 at 9:21 AM, wrote: > On 2021-08-23 20:56, cho8jeiv4aus at paperboats.net wrote: > > > Hi there. I had an idea recently for an onion service to improve the UX > > > > of sites that require a login. The site would have two onions: one for > > > > those who want to use onion auth and another for those who don't or are > > > > still setting it up. A user would first sign in with a > > > > username+password > > > > on the unauthenticated onion and click a button to generate a > > > > certificate associated with their account. Then they would add the > > > > public key to their browser and visit the authenticated onion. The > > > > application server would then match the pubkey used to authenticate > > > > with > > > > an account in the database, and log them in automatically. > > As for your case, you could maybe try client-side TLS certificates. > > I've had a similar idea for DoS protection. You have two onions, call > > them "open" and "closed". > > In the good times, you go to the "open" onion and register. It gives you > > a client authentication password for "closed" and redirects you there. > > On subsequent logins, you just go straight to the "closed" onion. (In > > theory, it's enough to have the key get you to the login screen - it > > doesn't actually have to replace authentication) > > Then, when the attack comes, it will take down the "open" onion. > > However, the "closed" onion is protected by client auth, and can be > > rate-limited by key. > > The only thing that would be needed for this is a special version of > > client authorization that allows the server to see which key is > > connecting, as opposed to "some key but you don't know which for privacy > > reasons". > > > As an operator, an alternative would be to generate one (authenticated) > > > > onion service per user and route them all to the same place with > > > > different Host headers, but that seems rather inefficient, and I don't > > > > know how well the tor daemon scales up to hundreds of onion services > > > > anyway. > > That's not great for the network. > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] compiling torsocks
Hi guys A complete non-dev/programmer here so please go easy on me. I'm trying to compile torsocks with 'mock', while 'tor' compiles okey for 'torsock' I fail with: ... configure.ac:20: comes from Automake 1.16.1. You should recreate configure.ac:20: aclocal.m4 with aclocal and run automake again. WARNING: 'automake-1.16' is probably too old. You should only need it if you modified 'Makefile.am' or 'configure.ac' or m4 files included by 'configure.ac'. The 'automake' program is part of the GNU Automake package: <http://www.gnu.org/software/automake> It also requires GNU Autoconf, GNU m4 and Perl in order to run: <http://www.gnu.org/software/autoconf> <http://www.gnu.org/software/m4/> <http://www.perl.org/> make[1]: *** [Makefile:600: Makefile.in] Error 63 make: *** [Makefile:466: all-recursive] Error 1 ... My setup is Centos 9 and obviously I do it with an rpm/spec. Would you guys be kind to guide me to troubleshoot this? many thanks, L. _______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] How to get source port from conn object
Hey all, I want to get to know the TOR codebase so I can contribute to the project. To do this I have been doing a few projects of just doing sort of basic tasks to get an idea for how it all works together. One thing that is giving me a bit of trouble but seems like it should be simple is finding the source port for a conn object. How do I find this and moreover how do I find the actual socket behind a given connection? In connection_t I see tor_socket_t but it seems to just be an int value. Thanks___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Tor can't read HiddenServicePort unix socket through group permissions when starting as root and using setgid?
Permissions are set so tor should be able to access through the `postfix-test-queue` user: > $ sudo ls -l /var/spool/postfix-test/public/smtpd > srw-rw-rw- 1 postfix-test postfix-test 0 █ > /var/spool/postfix-test/public/smtpd > $ sudo ls -l /var/spool/postfix-test > # ... > drwx--x--- 2 postfix-test postfix-test-queue 4096 █ public > $ sudo -u _tor-test id > uid=130(_tor-test) gid=141(_tor-test) > groups=141(_tor-test),1006(postfix-test-queue) > $ cat /etc/tor/instances/test/torrc | grep HiddenServicePort > HiddenServicePort 25 unix:/var/spool/postfix-test/public/smtpd > $ cat /run/tor-instances/test.defaults | grep User > User _tor-test Running `tor@test` via the default systemctl config shows: > $ ps -ax -o uid,gid,supgid,command | grep /usr/bin/tor > 130 141 141 /usr/bin/tor --defaults-torrc /run/tor-instances/test.defaults -f > /etc/tor/instances/test/torrc Which is missing the `postfix-test-queue` `1006` user which, for example shows up if I do: > $ sudo -u _tor-test sleep 1000 & ps -ax -o uid,gid,supgid,command | grep sleep > [1] 132314 > 0 141 141,1006 sudo -u _tor-test sleep 1000 Connecting using `sudo -u` works (the message indicates successful connection): > $ sudo -u _tor-test curl --unix-socket /var/spool/postfix-test/public/smtpd > http://localhost > curl: (1) Received HTTP/0.9 when not allowed But connecting via tor does not: > $ torsocks --ipv6 curl http://█.onion:25 > █ ERROR torsocks[134873]: Host unreachable (in > socks5_recv_connect_reply() at socks5.c:539) > curl: (7) Couldn't connect to server But does if I allow access to the socket to everyone: > $ sudo chmod "o+x" /var/spool/postfix-test/public/ > $ torsocks --ipv6 curl http://█.onion:25 > curl: (1) Received HTTP/0.9 when not allowed Tor's relevant source code: [Tor: lib/process/setuid.c Source File](https://tpo.pages.torproject.net/core/doc/tor/setuid_8c_source.html)_______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor can't read HiddenServicePort unix socket through group permissions when starting as root and using setgid?
I had a conversation about this on OFTC #tor: Is it intended that tor doesn't set supplementary groups when starting as root and then doing setgid? This describes my issue: https://tor.stackexchange.com/questions/23225/tor-cant-read-hiddenserviceport-unix-socket-through-group-permissions-when-star I see many threads on the internet of people claiming that tor unix socket permissions aren't working for them and while sometimes it turns out to be apparmor/SELinux, I think this might be biting other people too I think significant numbers of people might just be giving up and making their unix socket globally readable, or switching to numbered port based sockets rather than unix domain sockets. ketyn: we had a series of security surprises in the past with how we did groups and dropping privs, and we settled on what we do now as the safest option Alright, I guess I'll need to either make the sockets tor listens to owned by the tor user, or use socat to forward. Maybe there's a documentation fix to apply here though. tor forwards to* ketyn: What are you doing that would make that necessary? Is the default not working for you for some reason? Also, which socket(s) is(are) causing issues for you? Is it something in /run/tor? I want to make a tor hidden service listening to port 25, connected to a socket at /var/spool/postfix-test/public/smtpd owned by the user postfix-queue According to postfix, I'm then supposed to add whatever user I want to read to that socket to the group postfix-queue ketyn: hmmm for the control socket see the GroupWritable flags ControlSocket /run/tor/control GroupWritable RelaxDirModeCheck ControlSocketsGroupWritable 1 this is how you can add your username to the tor group and then have permissions to connect with a controller This is not a control socket. This is a hidden service. e.g. HiddenServicePort 25 unix:/var/spool/postfix-test/public/smtpd i don't think anybody has built something similar for the onion service lines but i think that tor is not dropping the groups, it simply is not letting you use the group permission there I want to be able to receive email over a hidden service. Like in https://github.com/ehloonion/onionmx > but i think that tor is not dropping the groups, it simply is not letting you use the group permission there Huh, ok. i say that because being in the group, for the control port, does work so it's not like the group got dropped check out the UnixSocksGroupWritable config option maybe it will help what you want ketyn: Out of curiosity, why is your smtpd listening on a socket rather than, say, 127.0.0.1:25? looks like no, it won't do what you want, because UnixSocksGroupWritable doesn't apply to hiddenservice lines bentham: Because it seems more secure and means I don't have to worry about port conflicts or firewalls, and deploy this setup to computers I don't have full control over. Here's another good reason I saw: https://github.com/freedomofpress/securedrop/issues/1261 "because applications sometimes (fairly) assume that localhost has a different threat model than an externally exposed service. Most recently, this common configuration lead to some hidden services exposing sensitive information through the Apache mod_status module" ... actually arma said "just barely possible that the network team would take a good patch" not quite the same as "probably not take" but yes, more generally, there is vast confusion about what permissions are *supposed* to be, what groups happen by default in debian/ubuntu, what the SELinux and Apparmor policies do, etc i think most people are probably doing it wrong but i don't even know what right is i end up putting all my onion service directories in /tmp/ so they work, and that cannot at all be right I also asked on stackexchange: https://tor.stackexchange.com/questions/23225/tor-cant-read-hiddenserviceport-unix-socket-through-group-permissions-when-star/23226 --- Original Message --- On Tuesday, July 5th, 2022 at 5:30 AM, keyandthegate via tor-dev wrote: > Permissions are set so tor should be able to access through the > `postfix-test-queue` user: > >> $ sudo ls -l /var/spool/postfix-test/public/smtpd >> srw-rw-rw- 1 postfix-test postfix-test 0 █ >> /var/spool/postfix-test/public/smtpd >> $ sudo ls -l /var/spool/postfix-test >> # ... >> drwx--x--- 2 postfix-test postfix-test-queue 4096 █████ public >> $ sudo -u _tor-test id >> uid=130(_tor-test) gid=141(_tor-test) >> groups=141(_tor-test),1006(postfix-test-queue) >> $ cat /etc/tor/instances/test/torrc | grep HiddenServicePort >> HiddenServicePort 25 unix:/var/spool/postfix-test/public/smtpd >> $ cat /run/tor-instances/test.defaults | grep User >> User _tor-test > > Running `tor@test` via the defa
[tor-dev] Want to build circuit via unpublished relay, can't add microdesc using control port
Hello everyone. I'm experimenting with Tor network and wanted to build a circuit via unpublished relay (PublishServerDescriptor 0). To do so, I set up a relay, got its authority descriptor, imported it with +POSTDESCRIPTOR in the client using control port and tried to build a circuit using its fingerprint with EXTENDCIRCUIT. Everything works fine with UseMicrodescriptors 0, however with MicroDescriptors activated, the client does not detect imported (full) descriptor, returning: 552 No descriptor for "fingerprint here" I found no way to import microdescriptor using control port and no other means to use unpublished nodes. How can I add microdesc which is not in consensus into router? Or how can I build circuit with a relay not in consensus otherwise? OpenPGP_signature Description: OpenPGP digital signature _______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Blacklist all domains, whitelist .onion,.exit
Hello.
I am trying to make a tor only allow traffic through onion services and exit
nodes.
I would like to blacklist all domains first, as that is simple and does not
need to be updated,
then whitelist all onions and exits.
Reason: I am hosting an onion service, but I don't want any client traffic
comming from that
machine.
I've played with MapAddress, VirtualAddrNetworkIPV4, AutomapHostsOnResolve,
AutomaptHostsSuffixes, but nothing seems to work as intended above.
MapAddress *=127.0.0.1 does not report invalid conf, but the controller reports
it is using
invalid sytax because "*" be source or target.
I tricked the controller with MapAddress *.*=127.0.0.1, as every domain has a
dot, the controller
didn't report syntax error and this option is actually ignored.
If the above worked, then the next option would be the whitelisting:
MapAddress *.onion VIRTUAL_IP
Or possibly the AutomapHostsOnResolve 1 and AutomapHostsSuffixes .exit,.onion
would
handle that part hopefully.
I did the lazy way, the antivirus way, I downloaded the IANA TLD domain list
and used basic
string manipulation to make: MapAddress *.${domain} 127.0.0.1
And yes, as you may think, the list is huge that has to be on its own included
conf file, and also
prone to be outdated every time a new TLD is created. But it works, in a dumb
and prone to
mistakes, it works. Can this be done better? Not antivirus way of all is
permitted, some known
items are blocked. I would prefer all is blocked and some items are permitted.
The real objective was to block all non .onion and .exit targets coming from a
client, that the
controller reports with SOURCE_ADDR, but I didn't find an option to MapAddress
per client
or anything similar to that do manipulate addresses per client source, so that
is why I started doing this for all tor traffic, which is not what I really
want, but controlling targets per client.
publickey - nyxnor@protonmail.com - 0xA972D64E.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Bridges and Snowflakes detection attack
Anyone knows how he did it? Seems kind of wierd he says he is against oppressive regiments but doesn't give any useful information about what the issue is. Original Message On Jan 9, 2023, 10:16 AM, wrote: > Hi, https://github.com/scriptzteam/Tor-Bridges-Collector Seems an attacker > has found a way to enumerate ~30 snowflakes and many bridges. I couldn't > find any discussion about this in the archive. Thanks, > _______ tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev___________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [CRITICAL] DeepCorr Traffic Confirmation Attack
Hi, I was just reading a paper on traffic confirmation attacks over here https://arxiv.org/pdf/1808.07285v1.pdf. This attack runs with the help of deep learning algorithm called DeepCorr. This attack can be run in a Five Eyes country or an authoritarian regime like Russia where companies are compelled to cooperate with the government making this attack plausible. The ISP and the website operators are the two endpoints for this attack. This attack was able to achieve a success rate of over 96% which represents a serious threat to Tor users in these regions. The paper also includes some countermeasures on how to defeat this method of traffic confirmation. Thanks. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [CRITICAL] Deep Fingerprinting Traffic Correlation
Hi, I was the one who raised the issue of DeepCorr being able to perform traffic correlation with a high degree of accuracy but it seems like that WTF-PAD which is currently implemented in Tor does defend against the DeepCprr attack. I could be wrong but this seems to be my understanding. The feasability of this attack decreased when W-T (Walkie-Talkie) a half duplex anti-traffic correlation startegy is used. The accuracy with a W-T defense in place is 49% compared to a 90% accuracy with WTF-PAD. Thera There has been a new deep learning attack which is extremely effective against the current implementation of WTF-PAD in Tor. This new attacks is called Deep Fingerprining proposed here : https://arxiv.org/pdf/1801.02265.pdf. Thanks ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] New Proposal - CAA Extensions for the Tor Rendezvous Specification
Hi Shelikhoo,Your suggestion seems sound, and I’d like to see it progress further. However it is not in the CA/BF BR, so is unusable by CAs, and therefore out of scope of my project.I suggest you take up your new method with the CA/BF for addition to their BR.Thanks,QOn 5 May 2023, at 15:56, Shelikhoo wrote:
Hi Q!
I have an
alternative design of public key infrastructure for onion
services that I would like you to consider. I have described it
on https://gitlab.torproject.org/tpo/core/torspec/-/issues/171, and here
is a rephrase of it.
In order to
prove the ownership of an onion address and create a
certificate, the onion service operator generate public and
private key as usual, and sign [certificate public key,
certificate fields (like expiry date, Subject Common Name) and
extensions (like key usage)] with their onion service private
key, and place the signature and a copy of signed data as
non-critical extension of a CSR known as onion certificate seed.
This onion
certificate seed can be either self-signed or submitted to
certificate authority to become a full certificate. It can be
submitted to certificate authority over ACME for certificate
issuance. The onion key signature and signed data is copied to
the final certificate as non-critical extension after
validation.
For Onion
Native Application (like Tor Browser), a TLS certificate is
trusted if it is issued by a trusted CA, or it has a valid onion
certificate seed extension. This means this certificate issue
model does not absolutely need any cooperative CA to work, so
long as Tor Browser and other Tor Native application supported
it by default, it would work as expected. For some application
designed specifically for Tor, a onion service without a valid
onion certificate seed extension may be rejected. For
non-Onion-Native applications, a certificate issued by
certificate authority will be necessary for it to pass
validation.
It has the
following advantages compare to the plan mentioned in your
email:
1. Since the
certificate public key and expiry date is covered by onion key's
signature, Certification Authority Authorization record is not
necessary, as attacker could not generate a certificate under
the attacker's control, since attacker have no access to the
public key. This also allow certificate authority to issue
certificate without the need to have access to the Tor network
or the onion service. (CA don't wish to change the design of
their airtight certificate issuing environment, don't force
them)
2. For Onion
Native Application, this design works on day 1 without the need
of any cooperative CA. Since currently a lot of onion service is
access with Tor Browser, it will allow Tor Browser to push the
adaption of this design with its weight. CA hates to break
thing, this design gets things rolling to force trusted CAs to
adapt it.
3. For Onion
Native Application, this design allows valid certificate to be
generated without contacting third party and publishing the
onion service address. This would allow sensitive onion service
to use TLS encryption without revealing its address to third
party or public.
4. The onion
certificate seed can be generated offline, which allow it to be
stored in a secure/offline location.
5. It does
not require any change to the C-Tor/Arti implementation, since
it does not require either CA or even the hidden service request
certificate itself connected to the Tor network.
Shelikhoo
On 25/4/2023 1:02 pm, Q Misell via
tor-dev wrote:
Hi all,
I've spent some time working on ACME for Tor hidden
services (you may have seen discussion of this work on the
onion-advisors mailing list). Full details of the project are
available at https://acmeforonions.org.
Attached is my proposal for a change to the Tor Rendezvous
Specification to support the inclusion of CAA records in
hidden service descriptors.
My fork of Tor implementing publishing these records is
available at https://github.com/as207960/tor.
Thanks,
Q
Any statements
contained in this email are p
Re: [tor-dev] Proposal for a New Web App to Configure Tor Nodes
On Sonntag, 25. August 2024 15:07:48 CEST Alessandro Greco via tor-dev wrote: > I have been thinking about creating a web app that generates a script to > configure a Tor node based on the settings defined by the user. > I'm not sure if something like this already exists, but I think it could be > very helpful. If you don't know: https://tor-relay.co/ might be helpful. Oh, I just see that Felix's tor configurator is offline. https://github.com/flxn/tor-relay-configurator Then your development comes at exactly the right time. ;-) -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom! signature.asc Description: This is a digitally signed message part. ___________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for a New Web App to Configure Tor Nodes
On Donnerstag, 29. August 2024 08:40:08 CEST George Hartley via tor-dev wrote: > 1. You MUST have read the manual, at least the entries explaining the > settings in your Tor configuration file. Please take a look at it here: > https://2019.www.torproject.org/docs/tor-manual.html.en ^^ I also prefer the Classic Tor Project websites for many things, but this man page is over 5 years out of date. Type 'man tor' or 'man torrc' in the console or use current html pages: https://manpages.debian.org/main/tor/tor.1.en.html or https://manpages.debian.org/main/tor/torrc.5.en.html > As far as I know, it never did much - the relays do not have a proper > configuration, the standard nickname, etc. The Tor Relay Configurator prevented exactly that. A clean torrc was produced, IPv4 or dual stack. Many years ago I produced my first torrc myself using Felix's website and I have recommended tor-relay.co to many people. -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom! signature.asc Description: This is a digitally signed message part. ___________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Sharing Circuits Between Onion Servers and Clients
On Tuesday, October 22nd, 2024 at 9:04 PM UTC, Watson Ladd wrote: > On Tue, Oct 22, 2024 at 3:47 AM stifle_savage042--- via tor-dev > tor-dev@lists.torproject.org wrote: > > > Hi all, > > > > I want to promote some recent work of mine in the hope that someone here > > will find it interesting or useful. In my most concise language, it is a > > "decentralized, asynchronous entropy generator protocol." I've made a > > somewhat complete demo implementation so far. Here's the repository: > > https://github.com/devnetsec/rand-num-consensus. The integrity of the > > entropy can only be compromised if all nodes in the ring are malicious and > > coinciding. Currently, a Tor client cannot anonymously connect to an onion > > service by directly contacting the rendezvous point, because that relay > > could have been chosen maliciously by the onion server. I wager that a > > scheme like this could enable onion servers and clients to share the same > > circuit. Both parties would have a guarantee that their relays were chosen > > randomly. > > > > The most similar solution I could find to this was in the TorCoin paper, > > but it appears to require a more complicated zero-knowledge proof. If there > > is serious interest in this, I'd be willing to write a proposal draft. > > Besides implementation difficulty, is there any outstanding flaw in this > > idea? > > > Uh, yes. Depending on how we class implementation difficulty. > - A node can go offline before revealing to influence the random > choice. This is very hard to deal with in general. > - Encryption isn't a commitment, particularly not with AES-GCM > I don't think my README explanation is quite clear enough. The purpose of encrypting "blocks" is to allow each node to be confident that its peers cannot manipulate the consensus in a way that jeopardizes its randomness (I suppose the consensus can be manipulated, but the result would still be random). It's as if a group of people each secretly write down a number 0 through n on a slip of paper, put those slips in a hat, then publicly sum these numbers once enough people have added their slips, and consider the remainder of that sum, when divided by n, the consensus. Then they can each truthfully testify that the consensus is random, so long as they are confident in the randomness of their own random number. A participant would have to know all the numbers their peers chose to successfully make the consensus equal the malicious target value. If a node is offline during the routine, the client will simply see one less signature on the consensus. I partially agree with your first point though. Currently, a node can stall the consensus by refusing to publish its reveal key. I apologize for that broken link. Dylan Downey [devnetsec] > Sincerely, > Watson Ladd > > > Best Regards, > > > > Dylan Downey [devnetsec] > > ___ > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > > > -- > Astra mortemque praestare gradatim-BEGIN PGP MESSAGE- owGVVl2IJUcVnvw9ZEQIGhZRhOMgrDH33lkmA+KAq5PZJTuQJWazIQ8Slrrdp7sr t7qqp6r63vSKKIiQvIWIICIYiI+C5CEJInkIxBXiYx7y5kN8chH0LQ8K+p2qvndm QhTcgeV2d9Wpc77vO9+pVz5739b2hWsnx+/96qGjnXv+dHe+VX9h9zdPWbrZcyjV MKGniujm7Glvz5YT2ru0t08q0jcPLu3Td6/TszePJvScisFZelKVJa28i3ywvX2Z cpAUAJtPtz52sP+Nj37028PrFKKuDN8KaqlqvrS/N51OaakVReenJS8RY/z1HaND DDM8dd69wEWcOV+vj7qMdZfpmiZlzER+p+djWikbEYCwpcVCCq5l8lwwXq+cX5Cr qNWWSVuKDVPjOsYPZCgrHT407JlW2hiqtC1JRyyNeIe8bU3OUx+46s2Mji21A7Uu RCqcLXRgMsrWPcqapG2BFO2U6WyvjL7NgFKFwRaNd9b1geSD6waq2bJXKFTSjq5w ZrZDxxeXTK0qGVEkt5UkWbi2M4y6Sm4daXloEUVFDSqCo0r5GV1DthdDKs9z54JG 5OGAmhi7cLC7W+vY9PMZQu0CZcsxcLHrlS2ntm+nKCWwDX2Y0c2GU+2113EQ4CTi OudCWXLWDDTnlBXwBgLAqxJKyLqSwxpkL8gpL+UYXWgpHcdhmwZsJT7O6Kj3HqEN tKfoJpAojBbOcIx1EcudHVpsxIHI0EINwnLKIZXOfqkLpvlApQbdMa+LqkisZShs ybeXcniHg+MEmRcKZGb6PRsle3pTUqMA/ZzZUtE4oHGat9Q7pHCn5zIgF+HV6JcU CnwVDXghoxcSHULIcdmquTm/dUQiFRukpNAIUHJCUAhRaF/0Os7ocRcb6pSPGriu TtNUBMWBvchjIdiqfS4HC0XMYxFCsWvNMNu0ixAs+r1LQbfaKA8JmT5p6XhMOfUA 0kpVrNSGUlB0BBSRUcceUPZRJK+6jpVPdXg+6cEE8mudzxIBhipCIrfZu+nCupXh smbRvKsAYdIXluIgYJNUsu68fKoOE3RFKYqT/kzEOhiCjnIMwkDrylDpVSWAcdBJ g+ebpNRVpYveRChNh/FIZaHvPoYIiCRsZdRqfSYhivq2GA4we7aZ0MDojSvccV6L mI1bAWmwqML/OE9wn9Jhao3UPrVDU1VG3GjOlaDkeclqXZi2lenZFlkNmT2EAJtQ unSn5BYIIhogBZ9oQqoG4EAqyD7bisnnXrWFH7qUkg72oqgUnLQ6SqqTrCykqTwk Lh2XghxefWb6xNF1lL59TKWTbYDELsT4blw9vHL9KvGLHVxPjYEJpEdBAjKA3F1f N9lHut6DHRYX4TETVLkzN65YhJ3EhBPjAJKsiiaDhFfJXWwFDsTXRd8afdKxdM7o Da2yukPmMQO1MTCBQEGzQ973AjsUWcKGQ4qRAbUMyr52TKHvUn7nIwhLcz5zQpml nv0kgNWxFTEcYHrzNU2PQM4RFiz9UkmLetd3UnuHJOAAqUTYrmcxqqzg0q0kX3iw DN5LOMMLfCQWJ5ZidI6QG65LWUjG8
[tor-dev] Sharing Circuits Between Onion Servers and Clients
Hi all, I want to promote some recent work of mine in the hope that someone here will find it interesting or useful. In my most concise language, it is a "decentralized, asynchronous entropy generator protocol." I've made a somewhat complete demo implementation so far. Here's the repository: https://github.com/devnetsec/rand-num-consensus. The integrity of the entropy can only be compromised if all nodes in the ring are malicious and coinciding. Currently, a Tor client cannot anonymously connect to an onion service by directly contacting the rendezvous point, because that relay could have been chosen maliciously by the onion server. I wager that a scheme like this could enable onion servers and clients to share the same circuit. Both parties would have a guarantee that their relays were chosen randomly. The most similar solution I could find to this was in the TorCoin paper, but it appears to require a more complicated zero-knowledge proof. If there is serious interest in this, I'd be willing to write a proposal draft. Besides implementation difficulty, is there any outstanding flaw in this idea? Best Regards, Dylan Downey [devnetsec]-BEGIN PGP MESSAGE- owFVVE2IHEUYnZhETENivExOwc+JISizswTxsiCBbMSdIAiaiyQKNdVfdxdbXdVb P9v2gkfFgIScBA8SQRAv4i0XMaeIB68exFsuHjzpwYuExFc1M1lym+n+6r33vfeq b588OirGO3vz+3dOb0+O/PrXYlSfeW6yo0hoPS2KOfXCBAqWOmdbG5i8bZkcS8bj 3rpdshW1yjApQ6FhamzH+CFCnrR40bBj6pXWVClTkgoYDXjmgzI1WUfRcxX1jOaG 2oFa6wNJa6TyTFqYOoqap/mYJ0GTMnM7odUBl1MSfjCycdbY6Cm9sN1ANRt2IgAb soOVVs8mNL+wz9SKkoGStPVJpLRtpxl7ldxaUulPCxQRlDWYokq4Ge1A7QWf13Pc Wa+APGxRE0LntzY3axWauJgBarPkfcPBs9x0wpQbJrYbWMWz8dHP6FrDeffaqTAk 4xLiWrMUhqzRAy04q4LfcAB+VSkLMrZkvzbZJeeES+toJVVaHXQ4pmBbiZcz2o7O AVoPsIiuwQmpVcoMNMYGjFsztDgIQig0LHPKWUNend2+kkyLgUqFuMNyLgiZU1ta YUo+2E/kHYjDFMqlQJjL+B1rkc5EXVIjYP2C2ZBsLNw41J32HTLcIS/D8lS8mt0S CnnJBrmQVrsJHUVY4rIRC/300ZUTeVmfVvJNMioxeAEIqZyMKszosg0NdcIFBV/7 Q5mC0DikF3i1CI4qt1wHg6nMqyVSxLbVw6woUrK5uF61SguH6uiYOzRfSc3dh5ys vhdPokQ023APSjp2sDCGVHXRdSxc1u94LyIB6GqtW1YD3omAahywsxu7xvaay5pT 120F63KvMAoieJLbsb5xS1blp7gNZWpaupc5UEs9Wsmfgwc4KLnQVDpRJafYq1y+ p29HqapKyagDKqb8ilMYFDsGH+BNwq206NekBBRxqSiKy0nJu1wLV3p8ZK4MuOZ0 xfaGB7r+5Ap9UHwWj43Gxejs+KVjH728F2++/caJv395eHf9uTr+TPpWjYoTp9dP Xn0wenjq1uStV5598Z+7N4cP37z63Tsv/PjFmVPPf3/+xqfT8Q/Xf/5p9Pjj1+58 cu/G/d8ffX38/a2LX/374PXJ+I8vv7363p//nfvm5G9H/wc= =Xo6U -END PGP MESSAGE- gpg.key Description: Binary data ___________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Sharing Circuits Between Onion Servers and Clients
On Tuesday, October 22nd, 2024 at 11:24 PM UTC, Watson Ladd wrote: > > > On Tue, Oct 22, 2024, 4:15 PM wrote: > > On Tuesday, October 22nd, 2024 at 9:04 PM UTC, Watson Ladd wrote: > > > On Tue, Oct 22, 2024 at 3:47 AM stifle_savage042--- via tor-dev > > tor-dev@lists.torproject.org wrote: > > > > > Hi all, > > > > > > I want to promote some recent work of mine in the hope that someone here > > > will find it interesting or useful. In my most concise language, it is a > > > "decentralized, asynchronous entropy generator protocol." I've made a > > > somewhat complete demo implementation so far. Here's the repository: > > > https://github.com/devnetsec/rand-num-consensus. The integrity of the > > > entropy can only be compromised if all nodes in the ring are malicious > > > and coinciding. Currently, a Tor client cannot anonymously connect to an > > > onion service by directly contacting the rendezvous point, because that > > > relay could have been chosen maliciously by the onion server. I wager > > > that a scheme like this could enable onion servers and clients to share > > > the same circuit. Both parties would have a guarantee that their relays > > > were chosen randomly. > > > > > > The most similar solution I could find to this was in the TorCoin paper, > > > but it appears to require a more complicated zero-knowledge proof. If > > > there is serious interest in this, I'd be willing to write a proposal > > > draft. Besides implementation difficulty, is there any outstanding flaw > > > in this idea? > > > > > > Uh, yes. Depending on how we class implementation difficulty. > > - A node can go offline before revealing to influence the random > > choice. This is very hard to deal with in general. > > - Encryption isn't a commitment, particularly not with AES-GCM > > > > I don't think my README explanation is quite clear enough. The purpose of > encrypting "blocks" is to allow each node to be confident that its peers > cannot manipulate the consensus in a way that jeopardizes its randomness (I > suppose the consensus can be manipulated, but the result would still be > random). It's as if a group of people each secretly write down a number 0 > through n on a slip of paper, put those slips in a hat, then publicly sum > these numbers once enough people have added their slips, and consider the > remainder of that sum, when divided by n, the consensus. Then they can each > truthfully testify that the consensus is random, so long as they are > confident in the randomness of their own random number. A participant would > have to know all the numbers their peers chose to successfully make the > consensus equal the malicious target value. If a node is offline during the > routine, the client will simply see one less signature on the consensus. I > partially agree with your first point though. Currently, a node can stall the > consensus by refusing to publish its reveal key. > > > AES-GCM is not committing. There are messages that can be decrypted two > different ways with different keys. > > The commitment isn't the encryption of the random number, it's the signature on that ciphertext. See message::Block. The AES-GCM nonce makes sure that decryption fails if the incorrect reveal key is used. That's what I'm guessing you mean by "commitment," can you explain a bit more? Dylan Downey [devnetsec] > I apologize for that broken link. > > Dylan Downey [devnetsec] > > > Sincerely, > > Watson Ladd > > > > > Best Regards, > > > > > > Dylan Downey [devnetsec] > > > ___ > > > tor-dev mailing list > > > tor-dev@lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > > > > > > > > -- > > Astra mortemque praestare gradatim >-BEGIN PGP MESSAGE- owGNV8+LJEkV7nHXwxSIi4c5CAvPZmEUqqp72hGx1J7t6Wl3CnZY2elFUWSJynyZ GVuZETkRkV1T4x4ERXRB8A8QlMWreBEvelDYZQ7iXeameFEPzsWbsH4vIutHt72O 1Yeuyox4P773ve9F/Phjz+0Mrt19MH3vpy8c7175w99nO+WLt/76mqHTjn2ulkN6 LQt2xo4ODkw+pIP9g5ukAt24McGXr96jN06Ph/Q1Fbw19KrKc1o4G3gyOJQ/Soai ERhI24d0c3Ljc3/5zi+x+0s+6KLmN706UyXv3zx42evaNkrXfpzZ5nDLGsnn2YF9 YbL/rLiipctjEwufndz8PKI7ukcXgxuNRnSmFQXrRjmfrS31v1+utQ9+jF+ts29x FsbWlWu/ae16zyHd1aTqerh5svVuSgtlAgwTTDUwQN42TI4zxuOFdXOyBTXaMGlD oWKqbMv4gvhlpcWLih3TQtc1FdrkpAOWBjxDVqYk66jzXHT1mKaGmiU11gfKrMm0 Z6qVKTskPYzbPCnazaNvp2r9iIG38kuTVc4a23mSF7ZdUsmGnQIAEnawma3HuzS9 fsbUqJxhRWJbSJAoblsz8sq5saTlRwMrKmjUy1sqlBvTXUR7
[tor-dev] Metadata Cleaner is looking for a new co-maintainer
Hi, Many files contain hidden data, or metadata: * JPEG and other image files often contain information about where a picture was taken and which camera was used. * Office documents often contain information about their author, the date and time the document was created, as well as the complete changes history. To help you remove those metadata, Tails include Metadata Cleaner, a tool to remove metadata in a wide range of file formats: https://metadatacleaner.romainvigier.fr/ It is also available in Debian and on Flathub. Unfortunately, the future of Metadata Cleaner is compromised: it has no active maintainer anymore. The codebase is healthy and up-to-date: as far as we know, no urgent code change is required at the moment. Nevertheless, a widely used free software project needs active maintenance work, for example to triage issues reported by users, to review contributions, to maintain healthy relationships with upstream & downstreams, and to fix in a timely manner any critical bug or security vulnerability that might be discovered. And sooner or later, deeper code work might be necessary for the tool to keep working with newer versions of its dependencies. So we need at least 1 new co-maintainer to take over this duty. Metadata Cleaner is a Python GTK application built on top of mat2, which does the heavy lifting of metadata cleanup. Fun fact: mat2 originates from MAT, which was created in 2011 as part of a Tails/Tor GSoC project (https://0xacab.org/jvoisin/mat2). "Metadata Cleaner amplifies the usefulness of mat2 by making it usable by the users who need it the most, with a familiar graphical user interface. It nicely complements mat2-web, because it does not require trusting an online service with one's metadata: with Metadata Cleaner, the processing happens locally. As such, it's a key component of the ecosystem that enables users to work safely with sensitive documents." says Julien Voisin, author of MAT and mat2, who volunteered to be the other co-maintainer. If you want to become a co-maintainer of Metadata Cleaner, please get in touch at mat-...@boum.org (public mailing list). Thanks in advance, and many thanks to Romain Vigier for creating Metadata Cleaner! -- intrigeri, for the Tails Team jvoisin, mat2 developer ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Re: Make torsocks mutli-arch ready
Hey,
> This looks basically ok to me. More below:
thx for this fast reply! Sorry I'm a little bit busy the last days...
Btw. would it be possible to ship a new release the next days? So I can push
this new version to Debian trixie? As the soft freeze is happening at 15.
April.
> > But the torsocks script loads the libtorsocks by full path, so
> > torsocks wget will fail, as it loads the amd64 variant only.
> > ldconfig has this nice feature to find the correct library, if you only
> > add the name and that the library is in default search dir or you add a
> > conf file in / etc/ld.so.conf.d/.
>
> Maybe we could be a *little* more explicit and use a full path
> incorporating `${LIB}`? From ld.so(8):
> [...]
I see your point, but unfortunately it is not only lib64 vs. lib directory, as
Debian uses the different arch trippets for their lib paths. As you also want
different arm archs e.g.
/usr/lib/x86_64-linux-gnu/
and
/usr/lib/i386-linux-gnu/
for the complete list see
https://wiki.debian.org/Multiarch/Tuples
> This might head off some other weird corner cases (like some other
> `libtorsocks` ending up earlier in the library search path) and maybe
> give a stronger hint about what's going wrong in the error message you
> note below where the right library can't be found.
I see your point you are thinking at a warning like:
You enabled those archs but missing libtorsoks for following archs: X, Y, Z
I don't know if that is easy possible but I'll ask for help on Debian side.
> > #902792 https://bugs.debian.org/cgi-bin/902792
>
> This is an unfortunate failure mode, but yeah at least not worse than
> the current state.
>
> I was thinking about whether the torsocks script could try harder to
> detect this case, e.g. by itself checking what arch binary is being run
> and whether the corresponding library exists, but this would add a fair
> bit of complexity and would still miss cases where the target binary
> spawns more processes, possibly of different archs (e.g. `torsocks bash
> -c "wget ..."`)
Yes it would be nice, if torsocks could detect the arch correctly, but I also
thought at these complications about subprocesses.
Regards,
hefee
signature.asc
Description: This is a digitally signed message part.
_______
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Re: can tor use secondary groups to read FamilyKeyDirectory?
I added this as: https://gitlab.torproject.org/tpo/core/tor/-/issues/41046 kind regards, nusenu -- https://nusenu.github.io ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] About the key derivation algorithm used in the Control Port password authentication
Although several parts of Tor have been redesigned and upgraded over many years, the algorithm for the HashedControlPassword still remained the same. It still uses SHA-1 as the basis of the OpenPGP S2K algorithm, despite the fact that the algorithm has long-since been obsolete by newer and better hashing algorithms (on top of it, has had some practical collision attacks[1]). This is made worse by the fact that the S2K algorithm is not iterative (in the sense of recursive hashing), but rather repeats the salt+password many times in the hash digest until it reaches a certain amount of bytes. Theoretically, an attacker can expose this to autheticate into a Tor Control Port without having to know the password. Are there any plans to revamp the algorithm for newer Tor versions? [1]: https://shattered.io/ ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Make torsocks mutli-arch ready
Hey, in Debian we want to enable mutli-arch support for torsocks. To be able to run different binaries of different archs. We already splitted libtorsocks into own package, so you can now install e.g.: torsocks:amd64, libtorsocks:amd64, libtorsocks:i386, wget:i386 But the torsocks script loads the libtorsocks by full path, so torsocks wget will fail, as it loads the amd64 variant only. ldconfig has this nice feature to find the correct library, if you only add the name and that the library is in default search dir or you add a conf file in / etc/ld.so.conf.d/. Using just the libname makes the "safty" check `! -e "$SHLIB"` fail, as $SHLIB, is only the libname in our case. Can you have a look at the patch[1], if you think it is safe to ship this? [1] https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/master/debian/ patches/0004-Make-torsocks-multi-arch-foreign-compatible.patch The issue I see is this: If arch from executable and the corresponding libtorsocks is not installed, only a Error is printed, but still the executable is executed without routing trough tor. The disabled check in torsocks could somehow catch this, if we would knew the arch of the executable in advanced correctly (which we don't, so far). If we can make sure, that LD_PRELOAD would stop executing, if the library cannot be found. e.g. I install libtorsocks:amd64 and wget:i386 I get: $wget -O- -4 icanhazip.com XX.230.187.XX $ torsocks wget -O- -4 icanhazip.com ERROR: ld.so: object 'libtorsocks.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. [...] XX.230.187.XX [...] (installing libtorsocks:i386 fixes this) On the other side, this does not got worse; currently torsocks will print a different error see #902792 but still execute the binary without tor. So this safety check doesn't help here (and btw. installing libtorsocks:i386 does not fix this issue by itself you also need to call /usr/bin/i386-linux-gnu- torsocks). #902792 https://bugs.debian.org/cgi-bin/902792 Regards, hefee signature.asc Description: This is a digitally signed message part. _______ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] can tor use secondary groups to read FamilyKeyDirectory?
Hi, given the following example, tor fails to access the familykeydir folder. familykeydir has the following permissions: drwxr-x--- 2 root tor_reader id _tor uid=996(_tor) gid=993(_tor) groups=993(_tor),994(tor_reader) Is tor able to use secondary groups? When using sudo to switch to user _tor manually, it is possible to read files in that folder without problems. The problem does not happen when _tor's primary group is set to 'tor_reader'. Tested on debian. kind regards, nusenu -- https://nusenu.github.io _______ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Re: Make torsocks mutli-arch ready
Hey, > Ah, I was just looking for who to talk to about this. We actually just > released 2.5.0 today :) > > https://gitlab.torproject.org/tpo/core/torsocks/-/releases/v2.5.0 Great. On Debian side we have scripts that scan for new releases automatically. But I do not check those pages on a daily basis ;) So in case if it not a time critical, we get the information about a new release without any need from your side to inform me :) Regards hefee signature.asc Description: This is a digitally signed message part. ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Fine Tunneling For Tor Network | Tor Browser
Dear Tor-Dev, My name is Alessandro Greco and I am an Italian computer science student, I am finishing my studies and therefore I am working with my thesis and, as a topic, my supervisor and I have chosen the Tor network. The work done focuses entirely on the Tor Browser torrc configuration file, which is why I wrote Professor Steven Murdoch and he pointed me to this method in order to get in touch with the current Tor-Project developers. I state that I am not good in English and therefore I may be wrong or not give the right weight to the words. Going into the matter, I have developed an extension currently available only on Firefox reachable via the addresshttps://addons.mozilla.org/it/firefox/addon/tropea-project/. The initial goal was to simplify the tunneling phase, already editable through the Tor Browser torrc file, through commands such as ExitNode or ExcludeNode and much more. In order to simplify the use, I decided to create an extension and an "advanced" section, thus bringing back user-friendly graphic interfaces already well known to average users (the advanced section consists of a web page), which would allow modify the file to your liking without necessarily having to follow correct syntax and without having to go too far into the technical aspect of Tor Browser. Why? I decided to simplify the use of this configuration file because I believe that the path of "simplification" is the only (or in general one of the most important) way to be able to expand the catchment area by trying to accommodate more people who have the need for a network like Tor in order to be able to divert dictatorial censorship methods by governments. I want to give a practical example, let's consider the current situation between Russia and Ukraine. Although Putin belongs to Russia, it is also true that there is a large slice of Russian citizens who are intellectually suppressed every day given the limits of censorship by the Russian government and by other governments that limit the people in order to weaken Putin. Russia has currently blocked several social networks so that citizens can no longer share the atrocities that are happening, so much so that Anonymous has asked to publish photos and videos of what is happening through Google Maps or other applications that are currently not censored. In all this mess, I sincerely think that Tor can significantly affect the protection of truth and rights on the net. But it is also true that many people do not know how to use or modify these settings correctly or, more simply, they may not even know that they can change some settings. I strongly believe that a breakthrough in the world of Tor Networks is needed and so that citizens of every state in the world can have, without minimum IT requirements, the ability to fully use Tor Browser and consequently Tor. The thesis work is called Tropea-Project (Tropea is a type of onion from our area, if you want to do a search, look for Tropea Onion on Google) and it is completely free and open-source so that anyone can dare to add new features. The features currently available are the following: [Add-Remove] EntryNodes + StrictNodes [Add-Remove] ExitNodes + StrictNodes [Add-Remove] ExcludeNodes [Add-Remove] ExcludeExitNodes [Edit] GeoIPExcludeUnknow [Edit] Reset configuration [Torify App] Torify /*It depends on the application launched, [Working Application](https://github.com/NoNameoN-A/Tropea-Project/blob/main)*/ Please consider this project, at the moment I am struggling with the writing of the thesis so in a few weeks an extremely detailed guide on the whole programming aspect will be published so that I can help any student, programmer, hacker and anyone who wants to improve existing features or add new ones. I am very excited to write you this email and I hope you can consider this development of mine which focuses 100% of the forces so that the Tor project can help free as many people as possible from inhuman web slavery. I believe that online freedom is a humanitarian right on par with education and water, so I think it is appropriate to develop new features that simplify its use. If you have read this far I would ask you now to see the demonstration video that I have published so that you can see for yourself what it does and I hope you can understand how much I care. Now more than ever anyone needs Tor. * Technical notes on the extension * In order for it to be used correctly, you must first start a local script called tropea.js, which is located in the socket-tropea folder of the Repository. The extension code is in the tropea folder of the Repository. Since the exact path of the Tor Browser folder is required, due to the configuration of the torrc file, it would be ideal to install it when installing Tor Browser so as to further simplify the whole process so that they don't even have to run the local script as it might l
[tor-dev] Firefox Add-on for torrc functions of Tor Browser
Premise: I had already tried to write to this mailing list, I apologize if I send another email. Hi everyone I created a Firefox extension a few week ago that allows users to use some of the Tor Browser torrc-related features through a simple and intuitive graphical interface, like Orbot App -> settings. The project is under development but I would like to share it with you proposing to include it in the tor-project project so that it can be useful and reliable for anyone who wants to use it. The extension is currently functional and allows the modification of the following features: - Changing the origin of EntryNodes (+ StrictNodes). - Changing the origin of the ExitNodes (+ StrictNodes). - Exclusion of nodes relating to a given origin on the whole circuit. - Exclusion of nodes relating to a given origin on ExitNodes. - Exclusion of unrecognized (non-geolocalizable) nodes. - Section dedicated to the torify shell command (under development). But in the last few days I have noticed that in reality the most useful and requested features by any user are only the following: - Changing the origin of the ExitNodes (+ StrictNodes). - Exclusion of nodes relating to a given origin on the whole circuit. - Exclusion of nodes relating to a given origin on ExitNodes. The extension currently requires the launch of a local script that allows communication between the extension and the torrc file. This is another reason why your control and consent is useful, in order to prove to users the script does not include malicious code. The code is obviously Open Source and I hope you can consider this project which aims to contribute to the use of Tor-Project and to the development of new features. That said, Tropea is in an experimental phase and clearly presents all the problems of an early stage of development. I want to say that if on your part there may be interest in this project then I would be happy knowing that it can be considered by your development team, otherwise it makes no sense on my part to continue to make improvements. -- Regards, Alessandro Greco. Browse my WebSite! (autistici.org/aleff) Join the Free Software Foundation! (fsf.org) Support Electronic Frontier Foundation! (eff.org) Browse Privately. Explore Freely. (torproject.org) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] TOR socket for P2P in Python
Dear Tor Developers, in my application, a client connects to a server via: *client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)client_socket.connect(ip,port)* I want to replace these two lines to create a client_socket whose IP address cannot be seen by the server. The application is e-polling. I looked into - torpy (too many timeouts), - socks (requires too much external configuration), - and I have tor installed (unknown how to use from within python). I just need a replacement for the two-liner code above. *The ideal solution:* is device & OS agnostic, portable, uses no peripherals or configuration (i.e., just one pip package to install), and works reliably. Thus, the below torpy solution would have been ideal if it had worked reliably: *from torpy import TorClient # pip install torpy* *class Torsocket:* *def __init__(self,ip,port):self.mgr1= TorClient() self.tor = type(self.mgr1).__enter__(self.mgr1)self.mgr2= self.tor.create_circuit(3)self.circuit = type(self.mgr2).__enter__(self.mgr2)self.mgr3= self.circuit.create_stream((ip,port))self.socket = type(self.mgr3).__enter__(self.mgr3)def send(self,data): self.socket.send(data)def recv(self,size):return self.socket.recv(size)def __del__(self):for bla in [self.mgr3,self.mgr2,self.mgr1]: type(bla).__exit__(bla, None, None, None)* It replaces the two-liner from the beginning with the below one-liner *client_socket = Torsocket(*server_data.server_address)* My questions/requests: - Is torpy connected to the real tor network (or is it a little toy twin)? If it is the real tor network then I will close this issue and open another one. - Are practical solutions available to my problem already?, and which of them works best for user-friendliness? - Can a pip package for a torsocket be made, as described above? i.e., something like torpy, but connecting to the real network? - Can I offer anything so that the ideal solution would be crafted and packaged?* *) If it helps, I could tell a lot about my project and how I believe it is significant and will be for the greater good of people. It is a fully implemented 1000LOC LSAG+WOT decentral P2P e-polling program with GUI that shall return trust and sovereignty into the people's hands. The only missing bit is a reliable tor connection. _______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] TOR socket for P2P in Python
Sorry to bother again.
An equally good solution to replacing
*client_socket = socket.socket(socket.AF_INET,
socket.SOCK_STREAM)client_socket.connect(ip,port)*
with a TOR solution could be via a command line interface:
os.system("torsocketprogram -send 123.45.67.89 9000 filename.bytes") and
os.system("torsocketprogram -recv 123.45.67.89 9000 filename.bytes").
Am Do., 11. Aug. 2022 um 11:27 Uhr schrieb Martin Neuenhofen <
martinneuenho...@googlemail.com>:
> Dear Tor Developers,
>
> in my application, a client connects to a server via:
>
> *client_socket = socket.socket(socket.AF_INET,
> socket.SOCK_STREAM)client_socket.connect(ip,port)*
>
> I want to replace these two lines to create a client_socket whose IP
> address cannot be seen by the server. The application is e-polling.
>
> I looked into
>
>- torpy (too many timeouts),
>- socks (requires too much external configuration),
>- and I have tor installed (unknown how to use from within python).
>
> I just need a replacement for the two-liner code above.
>
> *The ideal solution:* is device & OS agnostic, portable, uses no
> peripherals or configuration (i.e., just one pip package to install), and
> works reliably.
> Thus, the below torpy solution would have been ideal if it had worked
> reliably:
>
> *from torpy import TorClient # pip install torpy*
> *class Torsocket:*
>
>
>
>
>
>
>
>
>
>
>
>
> *def __init__(self,ip,port):self.mgr1= TorClient()
> self.tor = type(self.mgr1).__enter__(self.mgr1)self.mgr2=
> self.tor.create_circuit(3)self.circuit =
> type(self.mgr2).__enter__(self.mgr2)self.mgr3=
> self.circuit.create_stream((ip,port))self.socket =
> type(self.mgr3).__enter__(self.mgr3)def send(self,data):
> self.socket.send(data)def recv(self,size):return
> self.socket.recv(size)def __del__(self):for bla in
> [self.mgr3,self.mgr2,self.mgr1]: type(bla).__exit__(bla, None, None, None)*
>
> It replaces the two-liner from the beginning with the below one-liner
> *client_socket = Torsocket(*server_data.server_address)*
>
> My questions/requests:
> - Is torpy connected to the real tor network (or is it a little toy twin)?
> If it is the real tor network then I will close this issue and open another
> one.
> - Are practical solutions available to my problem already?, and which of
> them works best for user-friendliness?
> - Can a pip package for a torsocket be made, as described above? i.e.,
> something like torpy, but connecting to the real network?
> - Can I offer anything so that the ideal solution would be crafted and
> packaged?*
>
> *) If it helps, I could tell a lot about my project and how I believe it
> is significant and will be for the greater good of people. It is a fully
> implemented 1000LOC LSAG+WOT decentral P2P e-polling program with GUI that
> shall return trust and sovereignty into the people's hands. The only
> missing bit is a reliable tor connection.
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] TOR socket for P2P in Python
Dear Matt Traudt,
Thank you for your answer.
Three remarks:
1) I only found your answer coincidentally when I googled for LSAG + WOT.
It would have been very nice if you had let me know that you answered.
2) Your answer sort of only repeats what is already written on Overflow.
Since that was unhelpful to me, I had asked the question your answer refers
to.
3) Your answer leaves out all the critical bits. Just to name the very
first, which caused the beginning of this conversation: The proxy did not
work because in windows the command "tor.exe" does nothing unless using the
expert bundle. Now, play a game and try to find the download link for the
expert bundle. I have lots of other things that leave me puzzled but it
would be unsuitable to post them publicly. Please feel invited to get in
touch if you want to have a discussion on certain things that appear to me
as dramatic design flaws.
Am Do., 11. Aug. 2022 um 17:13 Uhr schrieb Martin Neuenhofen <
martinneuenho...@googlemail.com>:
> Sorry to bother again.
> An equally good solution to replacing
>
> *client_socket = socket.socket(socket.AF_INET,
> socket.SOCK_STREAM)client_socket.connect(ip,port)*
> with a TOR solution could be via a command line interface:
> os.system("torsocketprogram -send 123.45.67.89 9000 filename.bytes") and
> os.system("torsocketprogram -recv 123.45.67.89 9000 filename.bytes").
>
> Am Do., 11. Aug. 2022 um 11:27 Uhr schrieb Martin Neuenhofen <
> martinneuenho...@googlemail.com>:
>
>> Dear Tor Developers,
>>
>> in my application, a client connects to a server via:
>>
>> *client_socket = socket.socket(socket.AF_INET,
>> socket.SOCK_STREAM)client_socket.connect(ip,port)*
>>
>> I want to replace these two lines to create a client_socket whose IP
>> address cannot be seen by the server. The application is e-polling.
>>
>> I looked into
>>
>>- torpy (too many timeouts),
>>- socks (requires too much external configuration),
>>- and I have tor installed (unknown how to use from within python).
>>
>> I just need a replacement for the two-liner code above.
>>
>> *The ideal solution:* is device & OS agnostic, portable, uses no
>> peripherals or configuration (i.e., just one pip package to install), and
>> works reliably.
>> Thus, the below torpy solution would have been ideal if it had worked
>> reliably:
>>
>> *from torpy import TorClient # pip install torpy*
>> *class Torsocket:*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *def __init__(self,ip,port):self.mgr1= TorClient()
>> self.tor = type(self.mgr1).__enter__(self.mgr1)self.mgr2=
>> self.tor.create_circuit(3)self.circuit =
>> type(self.mgr2).__enter__(self.mgr2)self.mgr3=
>> self.circuit.create_stream((ip,port))self.socket =
>> type(self.mgr3).__enter__(self.mgr3)def send(self,data):
>> self.socket.send(data)def recv(self,size):return
>> self.socket.recv(size)def __del__(self): for bla in
>> [self.mgr3,self.mgr2,self.mgr1]: type(bla).__exit__(bla, None, None, None)*
>>
>> It replaces the two-liner from the beginning with the below one-liner
>> *client_socket = Torsocket(*server_data.server_address)*
>>
>> My questions/requests:
>> - Is torpy connected to the real tor network (or is it a little toy
>> twin)? If it is the real tor network then I will close this issue and open
>> another one.
>> - Are practical solutions available to my problem already?, and which of
>> them works best for user-friendliness?
>> - Can a pip package for a torsocket be made, as described above? i.e.,
>> something like torpy, but connecting to the real network?
>> - Can I offer anything so that the ideal solution would be crafted and
>> packaged?*
>>
>> *) If it helps, I could tell a lot about my project and how I believe it
>> is significant and will be for the greater good of people. It is a fully
>> implemented 1000LOC LSAG+WOT decentral P2P e-polling program with GUI that
>> shall return trust and sovereignty into the people's hands. The only
>> missing bit is a reliable tor connection.
>>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] New Proposal - CAA Extensions for the Tor Rendezvous Specification
Hi all, I've spent some time working on ACME for Tor hidden services (you may have seen discussion of this work on the onion-advisors mailing list). Full details of the project are available at https://e.as207960.net/w4bdyj/AX8Ffqsd Attached is my proposal for a change to the Tor Rendezvous Specification to support the inclusion of CAA records in hidden service descriptors. My fork of Tor implementing publishing these records is available at https://e.as207960.net/w4bdyj/XMN03dmD Thanks, Q -- Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK3718474 and № UK3718468, respectively. Filename: xxx-rend-caa.txt Title: CAA Extensions for the Tor Rendezvous Specification Author: Q Misell Created: 2023-04-25 Status: Open Overview: The document defines extensions to the Tor Rendezvous Specification Hidden Service descriptor format to allow the attachment of DNS style CAA records to Tor hidden services to allow the same security benefits as CAA provides in the DNS. Motivation: As part of the work on draft-misell-acme-onion [I-D.misell-acme-onion] at the IETF it was felt necessary to define a method to incorporate CAA records [RFC8659] into Tor hidden services. CAA records in the DNS provide an mechanism to indicate which Certificate Authorities are permitted to issue certificates for a given domain name, and restrict which validation methods are permitted for certificate validation. As Tor hidden service domains are not in the DNS another way to provide the same security benefits as CAA does in the DNS needed to be devised. More information about this project in general can be found at https://e.as207960.net/w4bdyj/Gm2AylEF Specification: To enable maximal code re-use in CA codebases the same CAA record format is used in Tor hidden services as in the DNS. To this end a new field is added to the second layer hidden service descriptor [tor-rend-spec-v3] § 2.5.2.2. with the following format: "caa" SP flags SP tag SP value NL [Any number of times] The contents of "flag", "tag", and "value" are as per [RFC8659] § 4.1.1. Multiple CAA records may be present, as is the case in the DNS. A hidden service's second layer descriptor using CAA may look something like the following: create2-formats 2 single-onion-service caa 0 issue "example.com" caa 0 iodef "mailto:secur...@example.com"; caa 128 validationmethods "onion-csr-01" introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3KHCZ... As the CAA records are in the second layer descriptor and in the case of a hidden service requiring client authentication it is impossible to read them without the hidden service trusting a CA's public key, a method is required to signal that there are CAA records present (but not reveal their contents, which may disclose unwanted information about the hidden service operator to third parties). This is to allow a CA to know that it must attempt to check CAA records before issuance, and fail if it is unable to do so. To this end a new field is added to the first layer hidden service descriptor [tor-rend-spec-v3] § 2.5.1.2. with the following format: "caa-critical" NL [At most once] Security Considerations: The second layer descriptor is encrypted and MACed in a way that only a party with access to the secret key of the hidden service could manipulate what is published there. Therefore, Tor CAA records have at least the same security as those in the DNS secured by DNSSEC. The "caa-critical" flag is visible to anyone with knowledge of the hidden service's public key, however it reveals no information that could be used to de-anonymize the hidden service operator. The CAA flags in the second layer descriptor may reveal information about the hidden service operator if they choose to publish an "iodef", "contactemail", or "contactphone" tag. These however are not required for primary goal of CAA, that is to restrict which CAs may issue certificates for a given domain name. No more information is revealed by the "issue" nor "issuewild" tags than would be revealed by someone makin
Re: [tor-dev] New Proposal - CAA Extensions for the Tor Rendezvous Specification
Yes, signed is what I meant. I will update the document. -- Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK3718474 and № UK3718468, respectively. On Thu, 27 Apr 2023 at 13:54, Ian Goldberg wrote: > On Tue, Apr 25, 2023 at 01:02:28PM +0100, Q Misell via tor-dev wrote: > > Security Considerations: > > The second layer descriptor is encrypted and MACed in a way that only > a party > > with access to the secret key of the hidden service could manipulate > what is > > published there. Therefore, Tor CAA records have at least the same > security as > > those in the DNS secured by DNSSEC. > > Did you mean "signed"? If it's just encrypted and MACed, then anyone who > can decrypt and check the MAC can also alter the contents, of course. > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://e.as207960.net/w4bdyj/Clnj1LKF > smime.p7s Description: S/MIME Cryptographic Signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] New Proposal - CAA Extensions for the Tor Rendezvous Specification
Hi Raph, Whilst I agree that in an ideal world CAs would be irrelevant, we do not live in an ideal world. My proposal is one of many ways that a certificate could be issued to hidden services. Issuing standard TLS certificates to .onion domains allows HTTPS without modification to the browser. This allows non Tor Browsers user agents to access the Tor network via a proxy (SOCKS etc), doing otherwise would require all browsers to understand Tor. It also opens up new opportunities such as payment processing as current PCI DSS requirements do not allow non-standard TLS. Current hidden services with HTTPS such as the BBC already use standard TLS certificates, however the process for these is extremely involved with current CAs. My IETF draft aims to make this a much simpler process via the already well-proven ACME. Thanks, Q -- Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK3718474 and № UK3718468, respectively. On Thu, 27 Apr 2023 at 13:59, Raphaël Fabre wrote: > Hey > > I've read your proposal, although I'm not sure to grap the totality of it. > I'm Raph the lead dev of this project -> > https://e.as207960.net/w4bdyj/YG6dkkyr > > I have a question, since .onion is basically a non ICANN domain name > system, why do you care about using Certificate Authorities ? Could you > instead store the TLS certificates in the name system, as TXT / CERT > records (similar to DANE) ? > > Doing this would allow TOR service providers to not rely on certificate > authorities, control their TLS certificates directly (self signed) and *do > not need at all to renew it*. > > happy to chat further > Raph > > --- Original Message --- > Le jeudi 27 avril 2023 à 14:45, Q Misell via tor-dev < > tor-dev@lists.torproject.org> a écrit : > > Hi all, > > I've spent some time working on ACME for Tor hidden services (you may have > seen discussion of this work on the onion-advisors mailing list). Full > details of the project are available at https://e.as207960.net/w4bdyj/xqviywZW > <https://e.as207960.net/w4bdyj/yBzJUPTT>. > > Attached is my proposal for a change to the Tor Rendezvous Specification > to support the inclusion of CAA records in hidden service descriptors. > > My fork of Tor implementing publishing these records is available at > https://e.as207960.net/w4bdyj/ItcJLhNd > <https://e.as207960.net/w4bdyj/LmAkW3uG>. > > Thanks, > Q > -- > > Any statements contained in this email are personal to the author and are > not necessarily the statements of the company unless specifically stated. > AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, > Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company > registered in Wales under № 12417574 > <https://e.as207960.net/w4bdyj/pIFzAYXo>. ICO register №: ZA782876 > <https://e.as207960.net/w4bdyj/pZ2mD5UQ>. UK VAT №: GB378323867. EU VAT > №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: > 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks > in the UK, under № UK3718474 and № UK3718468, respectively. > > > smime.p7s Description: S/MIME Cryptographic Signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Calling Tor Volunteers and Developers! Help Shape the Future of Tor Relay Updates!
Dear Tor Volunteers and Developers, We are reaching out to you today to seek your invaluable expertise and insights in shaping the future of Tor relay updates. As part of an MSc Dissertation, a comprehensive study is underway to gain a deeper understanding of the significance of Tor relay updates from the unique perspective of developers like yourself. Your participation is pivotal to the success of this research, as we seek to explore your thoughts and opinions on a proposed automatic update mechanism for the relay. By lending your expertise, you will play a key role in advancing the health of the Tor network and enhancing the overall experience for millions of users around the globe. Rest assured that all your responses will be treated with the utmost care and confidentiality. To safeguard your data, the survey has been thoughtfully designed on an end-to-end encrypted platform, aligning with our commitment to ethical principles. We genuinely value your privacy and will handle your contributions with utmost respect and protection. We acknowledge the value of your time and effort, and we assure you that your input, which requires only 10 minutes, will wield a significant influence on the advancement of the Tor network. Don't miss out on this chance to contribute; the survey will remain open until August 5th. We invite you to join us today in shaping transformative research for Tor's bright future. Should you have any questions or require further information, please don't hesitate to contact us at s2450...@ed.ac.uk. We wholeheartedly welcome your feedback and queries, and your cooperation is genuinely appreciated. Together, we can make a meaningful difference and construct a stronger, more secure online world for everyone. Participate now and be an integral part of shaping the future of Tor relay updates through this link: https://cryptpad.fr/form/#/2/form/view/pb7wKm8zl0D62PsW93fz4wiW73i9nzDM-JxcrQEgMY0/ [https://cryptpad.fr/customize/images/opengraph_preview/og-form.png]<https://cryptpad.fr/form/#/2/form/view/pb7wKm8zl0D62PsW93fz4wiW73i9nzDM-JxcrQEgMY0/> Encrypted Form<https://cryptpad.fr/form/#/2/form/view/pb7wKm8zl0D62PsW93fz4wiW73i9nzDM-JxcrQEgMY0/> CryptPad: end-to-end encrypted collaboration suite cryptpad.fr Thank you for your essential role in this important journey. Best regards, Ravi Kumar s2450...@ed.ac.uk The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336. ___________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] UDP Application Support in Tor
Hi, I looked at the suggested solutions and I think there is another approach, which is much easier. I C it's pretty easy to encapsulate UDP segments inside TCP segments. Hence there is no need to re-organize the connection logic of tor relays. Instead it should be possible to make Guards, when receiving an UDP packet, to just add a TCP header and then it goes through the normal process. The exit nodes than removed the TCP header and pass the UDP segment on. Regards Vilgot tor-dev-requ...@lists.torproject.org schrieb am Donnerstag, 25. Januar 2024 um 18:49: > > > Send tor-dev mailing list submissions to > tor-dev@lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-requ...@lists.torproject.org > > You can reach the person managing the list at > tor-dev-ow...@lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. New Proposal - UDP Application Support in Tor > (Micah Elizabeth Scott) > > > -- > > Message: 1 > Date: Thu, 25 Jan 2024 09:49:02 -0800 > From: Micah Elizabeth Scott b...@torproject.org > > To: tor-dev@lists.torproject.org > Subject: [tor-dev] New Proposal - UDP Application Support in Tor > Message-ID: 79aa2de8-1ff9-4579-b87f-ee9792e9c...@torproject.org > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hello tor-dev folks! > > Late last year I started taking a close look at what it would take to > support applications on Tor which rely on UDP networking. This was > originally to be based on Nick's proposal, 339-udp-over-tor. > > The scope of this work so far has been specifically focused on end-user > application compatibility, and excludes fundamental changes to Tor's > network structure or protocols for now. > > This combination of approach and scope left me with more questions than > answers, so I started looking deeper into the available solutions along > with their expected benefits and risks. This proposal is the result of > that investigation. > > Please find the text attached, or in the torspec repo as proposal #348: > > https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/348-udp-app-support.md?ref_type=heads > > Unlike a typical proposal, this does not recommend any specific change > to the Tor implementation. Several possible changes are presented, but > ultimately the recommended approach is to use application-specific UDP > relays to achieve compatibility. > > Integrated approaches are also presented, where Tor does involve itself > in the transit of individual datagrams. These approaches offer > advantages only when they are also part of a long-term plan to offer > transport features beyond those offered by TCP. Until such a plan is > in-scope, specific UDP extensions cannot be offered with confidence. > > I would appreciate any feedback on this proposal, whether it's about > this particular shorter-term context or about longer-term plans to > achieve some kind of optional unreliable transport. > > Thanks for your time! > > --beth > -- next part -- > A non-text attachment was scrubbed... > Name: 348-udp-app-support.md > Type: text/markdown > Size: 58079 bytes > Desc: not available > URL: > http://lists.torproject.org/pipermail/tor-dev/attachments/20240125/8ae2ddc3/attachment.md > > > -- > > Subject: Digest Footer > > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > -- > > End of tor-dev Digest, Vol 154, Issue 9 > *** publickey - vilgot.bergquist@protonmail.com - 0xEC7AAFDD.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposal for Tor (Relay) Watchdog (Telegram) Bot
Dear Tor Project Developers, I hope this email finds you well. I am writing to share with you a project [1] I have been working on called Tor Watchdog Bot [2], and I believe it may be of interest to you. Tor Watchdog Bot is a Telegram bot designed to monitor the status of Tor relays and notify users when relays go offline. The intent behind creating this bot was to develop a user-friendly tool that allows anyone to easily keep track of their Tor nodes. I am fully aware that the bot is not currently ready for public release as it requires several bug fixes and improvements. Before proceeding with further development, I wanted to ensure that this project aligns with your interests and goals. In order to prioritize user privacy and security, I did not activate the backend feature with the actual functionality; instead, I activated a demo that always provides the same results but allows users to understand the type of response they would receive if it were active. In the README.md file, you will find detailed instructions on how to set up and test the bot. If you find this project interesting and believe it could be beneficial to the Tor community, I would be delighted to see Tor Project host this service. However, I understand the importance of avoiding any form of user profiling, so I want to ensure that any potential hosting solution prioritizes user privacy. The code for Tor Watchdog Bot is released under the GPLv3 license, so you are libre to use and modify it as you see fit. I would be thrilled to contribute to the development of this project if it aligns with your vision. Thank you for considering this proposal. I look forward to hearing your thoughts and feedback. Best regards, Aleff. [1] https://github.com/aleff-github/TorWatchdog [2] https://t.me/TorWatchdog_bot --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org) publickey - alessandro.greco.1@protonmail.com - 0x1D14CC10.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Cancel
Cancel what exactly? You can unsubscribe from the list by logging in to the account that you have created. Sincerely, George On Wednesday, August 21st, 2024 at 2:38 PM, tj wrote: > Sent from my iPhone > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature _______ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposal for a New Web App to Configure Tor Nodes
Hello everyone, I have been thinking about creating a web app that generates a script to configure a Tor node based on the settings defined by the user. Let me explain a bit further. This web app could work either entirely on the client side using JavaScript or on the server side. I believe a client-side-only approach is preferable because it avoids handling user data in any way and reduces the risk of man-in-the-middle attacks, although it doesn't completely eliminate it. The main use case would be for a user who wants to contribute by configuring a Tor node. Instead of manually writing all the various configurations — from downloading Tor to following the best practices after configuration — the user would simply need to select a series of options on a user-friendly page (user-friendly = easier setup => more wish to do it, which could realistically lead to more relays), download the auto-generated file, and run it with administrative privileges. I believe that developing such a web app could not only benefit the Tor network by encouraging the deployment of new nodes, but it could also be highly educational. Alongside the script to execute, a standard report could be generated to technically explain the function of each setting. Of course, there would be a standard section allowing for basic relay execution and an "advanced" section that opens up multiple functionalities for the user. I'm not sure if something like this already exists, but I think it could be very helpful. For instance, I often find myself scrolling through the manual to check for the latest updates applicable to the `torrc` file. With this web app, we could also create a "latest updates" section. This is just my rough idea, and if it proves useful not just for me but for the rest of the community as well, we could consider structuring a development project around it. Best regards, Aleff. --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org) publickey - alessandro.greco.1@protonmail.com - 0x1D14CC10.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for a New Web App to Configure Tor Nodes
We want people to be knowledgeable, and these "do it one time and forget about it" websites are not helping. I personally believe, that if you want to host a Tor node: 1. You MUST have read the manual, at least the entries explaining the settings in your Tor configuration file. Please take a look at it here: https://2019.www.torproject.org/docs/tor-manual.html.en 2. You MUST NOT be using a Tor-relay polluted data center or Host (Hetzner, OVH, NetCup). Please look at the current network diversity: https://metrics.torproject.org/bubbles.html 3. You should have a dedicated server, or at least a QEMU KVM, with 25 MBit/s or more of continuous, unlimited traffic. We used to have an official page, to incentivize random people who don't know much about IT in general to host a Tor node. As far as I know, it never did much - the relays do not have a proper configuration, the standard nickname, etc. Owners would abandon their relays or stop paying for the machine altogether. There needs to be targeted "advertising" for privacy conscious people, people who might already use the Tor browser. Maybe add some incentive to the starting page of Tor Browser, reminding users that we still need more relays. Just my 2 cents. Sincerely, George On Wednesday, August 28th, 2024 at 9:30 AM, Sergey Ponomarev wrote: > Hi Allef, > > For routers with OpenWrt (a FOSS firmware) you can install the Luci admin > panel plugin to configure Tor called luci-app-tor. This is probably the only > web GUI for Tor. > Currently it allows to configure very basic things like onion services so you > can access your router without a public IP. > There are no any configs for bridge or exit node, just from a client > perspective. > > Not sure if it will be useful for you, but it can be easily extended if > needed. > You can't install easily the Luci to Ubuntu but you may run the OpenWrt in > the virtual machine to try. > I made a few PRs to the tor for OpenWrt but the company that created the > package (Turris routers) doesn't interestd in this anymore. > > For a desktop distros loke Ubuntu you may find a similar tool called Webmin > that can be used for remote administration. Maybe you can create a plugin for > it. > > > 26 авг. 2024 г. 12:56:09 Alessandro Greco via tor-dev > : > > > Hello everyone, > > > > I have been thinking about creating a web app that generates a script to > > configure a Tor node based on the settings defined by the user. Let me > > explain a bit further. > > > > This web app could work either entirely on the client side using JavaScript > > or on the server side. I believe a client-side-only approach is preferable > > because it avoids handling user data in any way and reduces the risk of > > man-in-the-middle attacks, although it doesn't completely eliminate it. > > > > The main use case would be for a user who wants to contribute by > > configuring a Tor node. Instead of manually writing all the various > > configurations — from downloading Tor to following the best practices after > > configuration — the user would simply need to select a series of options on > > a user-friendly page (user-friendly = easier setup => more wish to do it, > > which could realistically lead to more relays), download the auto-generated > > file, and run it with administrative privileges. > > > > I believe that developing such a web app could not only benefit the Tor > > network by encouraging the deployment of new nodes, but it could also be > > highly educational. Alongside the script to execute, a standard report > > could be generated to technically explain the function of each setting. > > > > Of course, there would be a standard section allowing for basic relay > > execution and an "advanced" section that opens up multiple functionalities > > for the user. > > > > I'm not sure if something like this already exists, but I think it could be > > very helpful. For instance, I often find myself scrolling through the > > manual to check for the latest updates applicable to the `torrc` file. With > > this web app, we could also create a "latest updates" section. > > > > This is just my rough idea, and if it proves useful not just for me but for > > the rest of the community as well, we could consider structuring a > > development project around it. > > > > Best regards, > > > > Aleff. > > > > --- > > > > Browse my WebSite: aleff-gitlab.gitlab.io > > Use my PGP Public Key: > > pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A21
Re: [tor-dev] Proposal for a New Web App to Configure Tor Nodes
> The relays do not have a proper configuration, the standard nickname, etc. Why not make an image that has an install wizard to set nicknames etc, and keeps other settings up to date to best current practices? Saying that you *must* have digested the inner workings of Tor first is a little elitist at best. -- Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK3718474 and № UK3718468, respectively. On Fri, 30 Aug 2024 at 11:27, George Hartley via tor-dev < tor-dev@lists.torproject.org> wrote: > We want people to be knowledgeable, and these "do it one time and forget > about it" websites are not helping. > > I personally believe, that if you want to host a Tor node: > > >1. You MUST have read the manual, at least the entries explaining the >settings in your Tor configuration file. Please take a look at it here: >https://e.as207960.net/w4bdyj/8khjJeOgCmmxEx04 >2. You MUST NOT be using a Tor-relay polluted data center or Host >(Hetzner, OVH, NetCup). Please look at the current network diversity: >https://e.as207960.net/w4bdyj/lJHPMqju4IKuHFg7 >3. You should have a dedicated server, or at least a QEMU KVM, with 25 >MBit/s or more of continuous, unlimited traffic. > > > We used to have an official page, to incentivize random people who don't > know much about IT in general to host a Tor node. > > As far as I know, it never did much - the relays do not have a proper > configuration, the standard nickname, etc. > > Owners would abandon their relays or stop paying for the machine > altogether. > > There needs to be targeted "advertising" for privacy conscious people, > people who might already use the Tor browser. > > Maybe add some incentive to the starting page of Tor Browser, reminding > users that we still need more relays. > > Just my 2 cents. > > Sincerely, > George > > On Wednesday, August 28th, 2024 at 9:30 AM, Sergey Ponomarev < > stok...@gmail.com> wrote: > > Hi Allef, > > For routers with OpenWrt (a FOSS firmware) you can install the Luci admin > panel plugin to configure Tor called luci-app-tor. This is probably the > only web GUI for Tor. > Currently it allows to configure very basic things like onion services so > you can access your router without a public IP. > There are no any configs for bridge or exit node, just from a client > perspective. > > Not sure if it will be useful for you, but it can be easily extended if > needed. > You can't install easily the Luci to Ubuntu but you may run the OpenWrt in > the virtual machine to try. > I made a few PRs to the tor for OpenWrt but the company that created the > package (Turris routers) doesn't interestd in this anymore. > > For a desktop distros loke Ubuntu you may find a similar tool called > Webmin that can be used for remote administration. Maybe you can create a > plugin for it. > > 26 авг. 2024 г. 12:56:09 Alessandro Greco via tor-dev < > tor-dev@lists.torproject.org>: > > Hello everyone, > > I have been thinking about creating a web app that generates a script to > configure a Tor node based on the settings defined by the user. Let me > explain a bit further. > > This web app could work either entirely on the client side using > JavaScript or on the server side. I believe a client-side-only approach is > preferable because it avoids handling user data in any way and reduces the > risk of man-in-the-middle attacks, although it doesn't completely eliminate > it. > > The main use case would be for a user who wants to contribute by > configuring a Tor node. Instead of manually writing all the various > configurations — from downloading Tor to following the best practices after > configuration — the user would simply need to select a series of options on > a user-friendly page (user-friendly = easier setup => more
Re: [tor-dev] Proposal for a New Web App to Configure Tor Nodes
> Why not make an image that has an install wizard to set nicknames etc, and > keeps other settings up to date to best current practices? I think this could be a good idea, within the Tor installation panel you could structure a page that firstly contains the question “Do you want to contribute to the Tor network?” and then you could structure it in more detail starting perhaps with a Middle node. > 1) You MUST have read the manual... I also agree with this, but probably if we are talking about a Middle node, so a node that exposes neither the user of the node nor the creator of the node, then some sort of standard setting could be provided. If a user at installation decides they want to contribute it might be a good time to delve into this wonderful world. I often hear some people who think that “Contributing to the Tor network” is complex and “hacker stuff” but maybe they just don't know how to do it (besides not knowing the meaning of hacker) and, therefore, it could not only be useful to the network but would help people educate themselves by putting manuals and guides on display nicely. But the most important thing, for me, is that in addition to manuals and guides they are given the opportunity to contribute, at least for those who think they don't already have that opportunity. Think about Tor Browser, it is obvious that right now Tor Browser does a lot more than just routing traffic, but when it was born it did not have all this functionality. They make it extremely easy to use Tor many people now believe that Tor is only usable through Tor Browser and they don't even know that it is a proxy so probably including this possibility in the installation phase could give this help to all those users who would like to contribute but trivially don't know how to do it... Snowflake also comes to mind... -- Aleff publickey - alessandro.greco.1@protonmail.com - 0x1D14CC10.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 351: Making SOCKS5 authentication extensions extensible
Is there a reason why this proposal extends the existing username/password auth, instead of defining a new SOCKS5 authentication type? c.f. https://e.as207960.net/w4bdyj/5dQ6fT3QLm2aTfUx -- Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK3718474 and № UK3718468, respectively. On Mon, 9 Sept 2024 at 19:04, Nick Mathewson wrote: > (You can see this proposal rendered at > https://e.as207960.net/w4bdyj/WX0qiAbY3YcKg8M3 ) > > ``` > Filename: 351-socks-auth-extensions.md > Title: Making SOCKS5 authentication extensions extensible > Author: Nick Mathewson > Created: 9 September 2024 > Status: Open > ``` > > ## Introduction > > Currently, Tor implementations use > the SOCKS5 username and password fields > to pass parameters for stream isolation. > (See the `IsolateSocksAuth` flag in the C tor manual, > and the "Stream isolation" section > ([forthcoming]( > https://e.as207960.net/w4bdyj/hu9V3E9K4RDQug60 > in our [socks extensions](../socks-extensions.md) spec.) > > > Tor implementations also support SOCKS4 and SOCKS4a, > > but they are not affected by this proposal. > > > > The C Tor implementation also supports other proxy types besides SOCKS. > > They are not affected by this proposal > > because they either have other means to extend their protocols > > (as with HTTP headers in HTTP CONNECT) > > or no means to pass extension information > > (as for DNS proxies, iptables transparent proxies, etc). > > Until now, the rules for interpreting these fields have been simple: > all values are permitted, > and streams with unequal values may not share a circuit. > > But in order to integrate SOCKS connections into Arti's RPC protocol, > we additionally want the ability to send RPC "Object IDs"[^ObjectId] > in these fields. > To do this, we will need some way to tell > when we have received an object ID, > when we have received an isolation parameter, > and to avoid confusing them with one another. > > > Note that some confusion will necessarily remain possible: > > Since current Tor clients are allowed to send any value > > as SOCKS username and password, > > any value we specify here will be one which a client in principle > > _might_ have sent under the old protocol. > > Additionally, > since we are adding complexity to the interpretation of these fields, > it's possible we'll want to change this complexity in the future. > To do this, we'll want a versioning scheme to premit changes. > > ## Proposal > > > If accepted, the following can be incorporated into > > our [socks extensions](../socks-extensions.md) spec.) > > We support a series of extensions in SOCKS5 Username/Passwords. > Currently, > these extensions can encode a stream isolation parameter > (used to indicate that streams may share a circuit) > and an RPC object ID > (used to associate the stream with an entity in an RPC session). > > These extensions are in use whenever the SOCKS5 Username > begins with the 8-byte "magic" sequence `[3c 74 6f 72 53 30 58 3e]`. > (This is the ASCII encoding of ``). > > If the SOCKS5 Username/Password fields are present > but the Username does not begin with this byte sequence, > it indicates _legacy isolation_. > New client implementations SHOULD NOT use legacy isolation. > A SocksPort may be configured to reject legacy isolation. > > When these extensions are in use, > the next byte of the username after the "magic" sequence > indicate a version number. > Any implementation receiving an unrecognized or missing version > MUST reject the socks request. > > When the version number is `[30]` (the ascii encoding of `0`), > we interpret the rest of the Username field and the Password field > as follows: > > The remainder of the Username field encodes an RPC O
Re: [tor-dev] Tor over QUIC
- What are people's thoughts on this? To be honest, I don't really care about UDP support. Adding UDP support also would presumably add a lot of torrent load to the network, and yes I know that torrent clients can fall back to TCP and this is already an issue. Regarding TLS, it's still somewhat insecure, as it transmits the target domain name during the ClientHello packet (SNI char buf in the packet, aka. Server Name Indication). There was some work regarding ESNI (encrypted SNI) but Firefox removed it eventually. This would also need to be worked on. Just my quick thoughts on this. On Friday, October 4th, 2024 at 9:56 AM, Q Misell via tor-dev wrote: > Hi all, > > I know the discussion on how best to support UDP applications over Tor has > dragged on for a long time, so I thought what better to do than to throw > another item to bikeshed into the discussion :) > On a more serious note I think running Tor over QUIC would provide several > advantages - both for the current stream transport and for possible future > datagram transports. > > On a technical level I don't think this would require huge changes to the Tor > specification, circuit IDs map nicely to QUIC stream IDs, and datagram > packets - whatever form they take - can be sent as QUIC datagram frames (c.f. > RFC 9221). > The primary advantage I see QUIC providing is the removal of head of line > blocking. As Tor currently multiplexes everything over one TCP connection, a > single dropped packet will delay all circuits and streams. > This impacts bandwidth utilisation and makes Tor less than ideal for > real-time applications. > Given this it might make more sense to provide a mapping of Tor streams to > QUIC streams rather than Tor circuits - but this is a minor technical detail > to be worked out in any specification. > > Now, that's great and all, but is it secure? I think yes - although I haven't > done an in depth analysis yet. > QUIC is very resistant against de-anonymization by passive attackers - the > only thing a passive observer can see is a cryptographically generated random > connection ID. > QUIC also provides in-built padding frames to protect against traffic > analysis. > The connection setup and handshake is protected by the usual TLS mechanisms > (with a minimum version of TLS 1.3). We already know recent TLS versions to > be almost bullet proof if used correctly, > and TLS is already the base transport for Tor anyway. > A read of the security considerations section of RFC 9000 seems to confirm > that even an active attacker can at most cause a connection to fail. > Another concern is this making Tor traffic stand out more. This is a very > legitimate concern, however with the increasing deployment of HTTP/3 I don't > think it will make Tor stand out against the background of HTTP/3 traffic, > see: https://blog.cloudflare.com/http3-usage-one-year-on/ > > I recognise this is a rather large project - and may not be worthwhile. I > only expect this to be implemented in Arti, so deployment of Tor over QUIC in > the real world will take at least until Arti is widely used. > What are people's thoughts on this? > > Q > > Any statements contained in this email are personal to the author and are not > necessarily the statements of the company unless specifically stated. > AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, > Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered > in Wales under № 12417574, LEI 875500FXNCJPAPF3PD10. ICO register №: > ZA782876. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: > 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a > registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, > 46001, trading as Glauca Digital, is a company registered in Estonia under № > 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are > registered trademarks in the UK, under № UK3718474 and № UK3718468, > respectively. publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor over QUIC
- I don't understand why SNI is being be discussed here, ESNI/ECH wouldn't bring much to Tor, there are better ways than looking at the client hello to detect a Tor relay, starting by its IP being public. Hey, looks like you misunderstood me, I was not talking about relay detection, but malicious exit nodes gathering domain names even with DNS over TLS in place. -GH On Tuesday, October 8th, 2024 at 12:36 PM, trinity pointard wrote: > I think QUIC could be an improvement, though I'm worried adding QUIC wouldn't > remove the need for Tor over TLS, which might add more maintenance burden. > > Even with QUIC, we will need to support TLS for some time so as to not > partition the network. Also, it used to be that UDP was 2nd class citizen in > some networks, and you'd never be able to get as good of a connection over > UDP (both in term of bandwidth and drop rate). So we might need more than a > transition period, > and possibly have to support both ad vitam æternam. > > It might simplify the implementation of UDP-over-Tor, but to me that's > something that would come later, and wouldn't change much things if we also > have to support TLS (over QUIC might be simpler, but over TLS would still > have to exist). > > It would be interesting to know how much head of line blocking we get. > Between relays, i would expect it to be less frequent than between relay and > client, but any blocking between relay might impact a lot of people at once. > It may well be that if we try to measure that, we find that the network would > feel much faster with no HOL blocking, or it could be that we find the > problem is negligible today. > > QUIC connection migration might be something to look at. It sounds like > something that can be useful especially for mobile users whose IP might > change, currently that would reset their connection. But that might also be a > tracking hazard somehow? > > > I don't understand why SNI is being be discussed here, ESNI/ECH wouldn't > bring much to Tor, there are better ways than looking at the client hello to > detect a Tor relay, starting by its IP being public. > ECH would be good to have so that exit relays know even less about what they > transmit, but that's not for c-tor/arti to do (and ECH needs proper DNS > support over Tor, which could be considered a child item of UDP over Tor, or > something we can already do with DNS over tcp/tls/https, or something > orthogonal where a client could query directly the DNS of an exit node with > more than A//PTR). > > On Tue, 8 Oct 2024 at 10:29, George Hartley via tor-dev > wrote: > > > - What are people's thoughts on this? > > > > > > To be honest, I don't really care about UDP support. > > > > Adding UDP support also would presumably add a lot of torrent load to the > > network, and yes I know that torrent clients can fall back to TCP and this > > is already an issue. > > > > Regarding TLS, it's still somewhat insecure, as it transmits the target > > domain name during the ClientHello packet (SNI char buf in the packet, aka. > > Server Name Indication). > > > > There was some work regarding ESNI (encrypted SNI) but Firefox removed it > > eventually. > > > > This would also need to be worked on. > > > > Just my quick thoughts on this. > > > > > > On Friday, October 4th, 2024 at 9:56 AM, Q Misell via tor-dev > > wrote: > > > > > Hi all, > > > > > > I know the discussion on how best to support UDP applications over Tor > > > has dragged on for a long time, so I thought what better to do than to > > > throw another item to bikeshed into the discussion :) > > > On a more serious note I think running Tor over QUIC would provide > > > several advantages - both for the current stream transport and for > > > possible future datagram transports. > > > > > > On a technical level I don't think this would require huge changes to the > > > Tor specification, circuit IDs map nicely to QUIC stream IDs, and > > > datagram packets - whatever form they take - can be sent as QUIC datagram > > > frames (c.f. RFC 9221). > > > The primary advantage I see QUIC providing is the removal of head of line > > > blocking. As Tor currently multiplexes everything over one TCP > > > connection, a single dropped packet will delay all circuits and streams. > > > This impacts bandwidth utilisation and makes Tor less than ideal for > > > real-time applications. > > > Given this it
[tor-dev] Tor over QUIC
Hi all, I know the discussion on how best to support UDP applications over Tor has dragged on for a long time, so I thought what better to do than to throw another item to bikeshed into the discussion :) On a more serious note I think running Tor over QUIC would provide several advantages - both for the current stream transport and for possible future datagram transports. On a technical level I don't think this would require huge changes to the Tor specification, circuit IDs map nicely to QUIC stream IDs, and datagram packets - whatever form they take - can be sent as QUIC datagram frames (c.f. RFC 9221). The primary advantage I see QUIC providing is the removal of head of line blocking. As Tor currently multiplexes everything over one TCP connection, a single dropped packet will delay all circuits and streams. This impacts bandwidth utilisation and makes Tor less than ideal for real-time applications. Given this it might make more sense to provide a mapping of Tor streams to QUIC streams rather than Tor circuits - but this is a minor technical detail to be worked out in any specification. Now, that's great and all, but is it secure? I think yes - although I haven't done an in depth analysis yet. QUIC is very resistant against de-anonymization by passive attackers - the only thing a passive observer can see is a cryptographically generated random connection ID. QUIC also provides in-built padding frames to protect against traffic analysis. The connection setup and handshake is protected by the usual TLS mechanisms (with a minimum version of TLS 1.3). We already know recent TLS versions to be almost bullet proof if used correctly, and TLS is already the base transport for Tor anyway. A read of the security considerations section of RFC 9000 seems to confirm that even an active attacker can at most cause a connection to fail. Another concern is this making Tor traffic stand out more. This is a very legitimate concern, however with the increasing deployment of HTTP/3 I don't think it will make Tor stand out against the background of HTTP/3 traffic, see: https://e.as207960.net/w4bdyj/uJdzhSHvRZOf5dPL I recognise this is a rather large project - and may not be worthwhile. I only expect this to be implemented in Arti, so deployment of Tor over QUIC in the real world will take at least until Arti is widely used. What are people's thoughts on this? Q -- Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK3718474 and № UK3718468, respectively. smime.p7s Description: S/MIME Cryptographic Signature ___________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] When RFC 7686 and transparent proxies collide
Moin,
I've posted my thoughts on a potential solution to this in GitLab:
https://e.as207960.net/w4bdyj/9xhwJKBpklMvCk1U
It'd be great to hear some of your views on this.
Q
--
Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK3718474 and № UK3718468,
respectively.
On Mon, 15 Jan 2024 at 09:31, wrote:
> The thing with this issue, and their ignorant attitude to it, is that it
> is this easy to patch. The if statement that does this could simply be
> nested in another that checks for an environment variable, giving users
> an option to enable .onion resolution.
>
> diff --git a/lib/hostip.c b/lib/hostip.c
> index e7c318a..c0e2583 100644
> --- a/lib/hostip.c
> +++ b/lib/hostip.c
> @@ -693,12 +693,12 @@ enum resolve_t Curl_resolv(struct Curl_easy *data,
> struct connectdata *conn = data->conn;
> /* We should intentionally error and not resolve .onion TLDs */
> size_t hostname_len = strlen(hostname);
> - if(hostname_len >= 7 &&
> - (curl_strequal(&hostname[hostname_len - 6], ".onion") ||
> - curl_strequal(&hostname[hostname_len - 7], ".onion."))) {
> -failf(data, "Not resolving .onion address (RFC 7686)");
> -return CURLRESOLV_ERROR;
> - }
> +// if(hostname_len >= 7 &&
> +// (curl_strequal(&hostname[hostname_len - 6], ".onion") ||
> +// curl_strequal(&hostname[hostname_len - 7], ".onion."))) {
> +//failf(data, "Not resolving .onion address (RFC 7686)");
> +//return CURLRESOLV_ERROR;
> +// }
> *entry = NULL;
> #ifndef CURL_DISABLE_DOH
> conn->bits.doh = FALSE; /* default is not */
>
> On 2023-11-13 16:34, Alec Muffett wrote:
> > Hi Shawn!
> >
> > On Mon, 13 Nov 2023 at 15:54, Shawn Webb
> > wrote:
> >
> >> I agree that infoleaks, especially of .onion DNS requests, is
> >> problematic. However, I disagree that prohibiting it in broadly
> >> monocultured libraries (libcurl) is an advisable approach.
> >
> > If Curl is outright banning ".onion" at the level of the Curl source
> > code, I would not support that on the grounds that are described in
> > bullet point 2 of section 2, here, which I will requote in full:
> >
> > https://e.as207960.net/w4bdyj/IsIm9uMjppFq16LY
> >
> >> _2. Application Software: Applications (including proxies) that
> >> implement the Tor protocol MUST recognize .onion names as special by
> >> either accessing them directly or using a proxy (e.g., SOCKS
> >> [RFC1928]) to do so. Applications that do not implement the Tor
> >> protocol SHOULD generate an error upon the use of .onion and SHOULD
> >> NOT perform a DNS lookup._
> >
> > ...but I will also note that I have not (maybe I missed it?) seen
> > bullet point 3 being referenced in this thread:
> >
> >> _3. Name Resolution APIs and Libraries: Resolvers MUST either
> >> respond to requests for .onion names by resolving them according to
> >> [tor-rendezvous] or by responding with NXDOMAIN [RFC1035]._
> >
> > I see Curl/LibCurl in the context of an application (§2) which makes
> > calls into name resolution apis (§3). I regret that the text of §2
> > ("...that do not implement the Tor protocol...") is ambiguous in its
> > scope, and would prefer something about the app being incapable of
> > dealing with and unaware of the existence of multiple possible
> > name-resolution namespaces, instead.
> >
> > Likewise I feel that _"Applications that do not implement the Tor
> > protocol SHOULD generate an error"_ would benefit from being rewritten
> > to acknowledge that the desirable error _may_ come passively as a
> > consequence of the name resolution libraries that are called, r
[tor-dev] New BUG() call and stack-trace seen in the wild on 0.4.8.13 exit relay.
Hi, I noticed the following when checking journalctl logs from Tor: > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] > tor_bug_occurred_(): Bug: src/core/or/relay.c:2354: > connection_edge_package_raw_inbuf: Non-fatal assertion > !(conn->base_.marked_for_close) failed. (on Tor 0.4.8.13 )Nov 13 19:51:10 > matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: Tor 0.4.8.13: Non-fatal > assertion !(conn->base_.marked_for_close) failed in > connection_edge_package_raw_inbuf at src/core/or/relay.c:2354. Stack trace: > (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: > /usr/bin/tor(+0x1c8c5d) [0x62048e493c5d] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: > /usr/bin/tor(+0x94325) [0x62048e35f325] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: > /usr/bin/tor(+0x4335f) [0x62048e30e35f] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: > /usr/bin/tor(+0x11afa6) [0x62048e3e5fa6] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: > /usr/bin/tor(+0x10e8a2) [0x62048e3d98a2] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: > /usr/lib/libevent-2.1.so.7(+0x22b42) [0x7488c6f57b42] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: > /usr/lib/libevent-2.1.so.7(event_base_loop+0x4ff) [0x7488c6f593af] (on Tor > 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: > /usr/bin/tor(+0xd3da) [0x62048e2d83da] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: > /usr/bin/tor(+0xa947) [0x62048e2d5947] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: > /usr/lib/libc.so.6(+0x25e08) [0x7488c6527e08] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: > /usr/lib/libc.so.6(__libc_start_main+0x8c) [0x7488c6527ecc] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: > /usr/bin/tor(+0xba25) [0x62048e2d6a25] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] > connection_edge_package_raw_inbuf(): Bug: called on conn that's already > marked for close at src/core/or/relay.c:1870. (on Tor 0.4.8.13 ) I didn't have the time to actually look at the function in question, and I also left my Gitlab authenticator device (fully encrypted) at a friends / colleagues place, otherwise I would have likely opened a Gitlab ticket, given I figured out the actual bug behind it, if any. However, as I am unable right now and also not at my usual workplace, I included tor-dev in the recipients. Thanks. -GH publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature _______ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Re: Make torsocks mutli-arch ready
On 3/26/25 7:45 PM, Hefee wrote:
Hey,
This looks basically ok to me. More below:
thx for this fast reply! Sorry I'm a little bit busy the last days...
Btw. would it be possible to ship a new release the next days? So I can push
this new version to Debian trixie? As the soft freeze is happening at 15.
April.
Ah, I was just looking for who to talk to about this. We actually just
released 2.5.0 today :)
https://gitlab.torproject.org/tpo/core/torsocks/-/releases/v2.5.0
But the torsocks script loads the libtorsocks by full path, so
torsocks wget will fail, as it loads the amd64 variant only.
ldconfig has this nice feature to find the correct library, if you only
add the name and that the library is in default search dir or you add a
conf file in / etc/ld.so.conf.d/.
Maybe we could be a *little* more explicit and use a full path
incorporating `${LIB}`? From ld.so(8):
[...]
I see your point, but unfortunately it is not only lib64 vs. lib directory, as
Debian uses the different arch trippets for their lib paths. As you also want
different arm archs e.g.
/usr/lib/x86_64-linux-gnu/
and
/usr/lib/i386-linux-gnu/
for the complete list see
https://wiki.debian.org/Multiarch/Tuples
ld.so also supports `${PLATFORM}`, though I'm unclear whether it'd map
to precisely these directory names.
This might head off some other weird corner cases (like some other
`libtorsocks` ending up earlier in the library search path) and maybe
give a stronger hint about what's going wrong in the error message you
note below where the right library can't be found.
I see your point you are thinking at a warning like:
You enabled those archs but missing libtorsoks for following archs: X, Y, Z
I don't know if that is easy possible but I'll ask for help on Debian side.
Hmm, yeah that seems like it'd be helpful, particularly if we're not
able to pull off something with `${PLATFORM}` and `${LIB}.
#902792 https://bugs.debian.org/cgi-bin/902792
This is an unfortunate failure mode, but yeah at least not worse than
the current state.
I was thinking about whether the torsocks script could try harder to
detect this case, e.g. by itself checking what arch binary is being run
and whether the corresponding library exists, but this would add a fair
bit of complexity and would still miss cases where the target binary
spawns more processes, possibly of different archs (e.g. `torsocks bash
-c "wget ..."`)
Yes it would be nice, if torsocks could detect the arch correctly, but I also
thought at these complications about subprocesses.
Regards,
hefee
Thanks for reaching out!
-Jim
_______
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Proposal 356: Increasing netdoc strictness not considered (very) harmful
https://spec.torproject.org/proposals/356-desc-parsing-variance.html This proposal explains why we will not, in the future, generally worry about protocol changes that make strings that were formerly accepted as network documents become rejected in future versions. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Proposal 358: Unifying circuit handshake extensions
https://spec.torproject.org/proposals/358-unified-handshake-extensions.html This proposal suggests that we should unify the EXT_FIELD_TYPE namespace, which is currently shared between CREATE2 and INTRODUCE2 messages. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Proposal 357: Circuit key exporters: A better way to use KH
https://spec.torproject.org/proposals/357-circ-key-exporters.html This proposal declares a new way to use the "KH" output of our circuit handshake protocol in the future, to avoid the possibility of creating cross-protocol attacks. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick _______ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Proposal 355: Options for postquantum circuit extension handshakes
https://spec.torproject.org/proposals/355-revisiting-pq.html This proposal updates earlier proposals about postquantum cryptography in Tor circuit extensions, to handle changes in Tor and the PQ landscape since those proposals were written. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Call for comments on proposals 346, 354, and 358.
Hi, all! We're hoping to implement these proposals soon: https://spec.torproject.org/proposals/346-protovers-again.html https://spec.torproject.org/proposals/354-relaxed-restrictions.html https://spec.torproject.org/proposals/358-unified-handshake-extensions.html Barring major objections, we're going to change their state from "Open" to "Accepted" in about a week. If anybody would like to comment, either here or on the bugtracker (https://gitlab.torproject.org/tpo/core/torspec/), that would be great! best wishes, -- Nick ___________ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Proposal 359: Counter Galois Onion, Updated
https://spec.torproject.org/proposals/359-cgo-redux.html This proposal instantiates a new approach for encrypting relay cells on circuits, to prevent certain kinds of tagging attacks, to improve forward secrecy, and more. It is based on research by Jean Paul Degabriele, Alessandro Melloni, Jean-Pierre Münch, and Martijn Stam. You can read their paper at https://eprint.iacr.org/2025/583 This is important and subtle; I'd appreciate any feedback, especially from cryptographers. I plan to start implementing this quite soon, on the theory that, even if there _are_ flaws, it is very unlikely to be _worse_ than our current malleable relay encryption. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick _______ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Proposal 360: Limiting HSDesc size and amplification
https://spec.torproject.org/proposals/360-hsdesc-len-limit.html This proposal describes a mechanism for preventing some kinds of traffic-flooding attacks by HSDirs. It's based on some of Mike Perry's work on Proposal 349. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! best wishes, -- Nick _______ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Re: can tor use secondary groups to read FamilyKeyDirectory?
On Thu, Apr 3, 2025 at 6:29 PM nusenu via tor-dev wrote: > > Hi, > > given the following example, tor fails to access the familykeydir folder. > > familykeydir has the following permissions: > > drwxr-x--- 2 root tor_reader > > id _tor > uid=996(_tor) gid=993(_tor) groups=993(_tor),994(tor_reader) > > Is tor able to use secondary groups? > > When using sudo to switch to user _tor manually, it is possible to read files > in that folder without problems. > > The problem does not happen when _tor's primary group is set to 'tor_reader'. > Tested on debian. Hm. In src/lib/process.setuid.c, it looks like we're only calling setgroups() with a single gid from the password database, not with any additional groups. So I don't think the C tor implementation is set up to handle _switching_ to secondary groups when you're telling it to setuid. -- Nick ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Re: can tor use secondary groups to read FamilyKeyDirectory?
On Tue, Apr 08, 2025 at 08:32:24AM -0400, Nick Mathewson via tor-dev wrote: > > Is tor able to use secondary groups? > > Hm. In src/lib/process.setuid.c, it looks like we're only calling > setgroups() with a single gid from the password database, not with any > additional groups. So I don't think the C tor implementation is set > up to handle _switching_ to secondary groups when you're telling it to > setuid. I believe that choice was intentional because of security, long ago. The man page for the User torrc option says "On startup, setuid to this user and setgid to their primary group." More details at https://bugs.torproject.org/tpo/core/tor/848 including some useful insights from Steven Murdoch at the time. --Roger _______ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] [GSoC 2025] Graph-Based Relay Partitioning – Proposal and Repository
Dear Tor team, I recently submitted a proposal to Google Summer of Code 2025 titled "Graph-Based Analysis of Relay Partitioning in the Tor Network", focused on detecting partitioning patterns through graph data science techniques. Although the project is still in its proposal phase, I have already created a GitHub repository( https://github.com/valentinaschiavon99/tor-relay-partitioning-gsoc2025) where I’m documenting the structure, early diagrams, and test notebooks. I'm reaching out in case any of you have suggestions or would like to point me toward related work, potential pitfalls, or early contributions I could start working on (e.g., documentation or testing). Thank you very much for your time and for the opportunity to contribute to such an impactful project. Best regards, Valentina Schiavon Business Informatics student @ AAU Klagenfurt ,Austria https://www.linkedin.com/in/valentinaschiavon1/ https://github.com/valentinaschiavon99 valentinaschiavo...@gmail.com _______ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Proposal 361: Onion Association SANs in Certificates (OASIC)
https://spec.torproject.org/proposals/361-oasic.html This proposal describes Onion Association standardization, authenticated by TLS certificates. It specifies how this association is encoded in the certificate's Subject Alternative Name (SAN) field, providing meaningful SAN-based Onion Association authentication. This proposal was written by Paul Syverson, I'm announcing it on his behalf. -- Micah Anderson (he/him) Director of Engineering The Tor Project, Inc. <https://torproject.org> ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Proposal 361: Onion Association SANs in Certificates (OASIC)
https://spec.torproject.org/proposals/361-oasic.html This proposal describes Onion Association standardization, authenticated by TLS certificates. It specifies how this association is encoded in the certificate's Subject Alternative Name (SAN) field, providing meaningful SAN-based Onion Association authentication. This proposal was written by Paul Syverson, I'm announcing it on his behalf. Feel free to open tickets on gitlab, discuss here, or also on the Tor Forum. -- Micah Anderson (he/him) Director of Engineering The Tor Project, Inc. <https://torproject.org> ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Proposal 354: Relaxing Path Restrictions in Arti
https://spec.torproject.org/proposals/354-relaxed-restrictions.html This is a proposal to simplify the usage of Family, Subnet, and custom path restrictions in Arti, so that clients don't reveal information about their Guards or Bridges by way of which relays they use, or don't use, in circuits. The meat of the proposal is that Arti's circuit path construction will satisfy the following rules: 1. Choose the Exit, HSDir, IP, or RP without considering restrictions 2. Choose Guard, Bridge, and Vanguards hops without considering restrictions 3. Choose any remaining middle nodes such that subnet, relay family, and user family restrictions apply with respect to the next hop (Exit, HSDir, IP, or RP) 4. Reject any resulting circuits with A-A and A-B-A sub-paths 5. If building a conflux leg: Reject any circuits that share relays with the other conflux leg(s) in the current conflux set. This simplifies path construction logic and avoids many pitfalls and information leaks caused by restriction use. These pitfalls and information leaks are documented in the proposal. The spec ticket in gitlab will remain open for comment until April 2, 2025: https://gitlab.torproject.org/tpo/core/torspec/-/issues/307 Comment here is also acceptable. -- Mike Perry _______ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Re: Make torsocks mutli-arch ready
This looks basically ok to me. More below:
On 3/10/25 8:50 AM, Hefee via tor-dev wrote:
Hey,
in Debian we want to enable mutli-arch support for torsocks. To be able to run
different binaries of different archs.
We already splitted libtorsocks into own package, so you can now install
e.g.: torsocks:amd64, libtorsocks:amd64, libtorsocks:i386, wget:i386
But the torsocks script loads the libtorsocks by full path, so
torsocks wget will fail, as it loads the amd64 variant only.
ldconfig has this nice feature to find the correct library, if you only add the
name and that the library is in default search dir or you add a conf file in /
etc/ld.so.conf.d/.
Maybe we could be a *little* more explicit and use a full path
incorporating `${LIB}`? From ld.so(8):
```
In several places, the dynamic linker expands dynamic string tokens:
o In the environment variables LD_LIBRARY_PATH, LD_PRELOAD, and
LD_AUDIT,
...
$LIB (or equivalently ${LIB})
This expands to lib or lib64 depending on the
architecture (e.g., on x86-64, it expands to
lib64 and on x86-32, it expands to lib).
```
This might head off some other weird corner cases (like some other
`libtorsocks` ending up earlier in the library search path) and maybe
give a stronger hint about what's going wrong in the error message you
note below where the right library can't be found.
Using just the libname makes the "safty" check `! -e "$SHLIB"` fail, as
$SHLIB, is only the libname in our case.
Can you have a look at the patch[1], if you think it is safe to ship this?
[1] https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/master/debian/
patches/0004-Make-torsocks-multi-arch-foreign-compatible.patch
The issue I see is this:
If arch from executable and the corresponding libtorsocks is not installed,
only a Error is printed, but still the executable is executed without routing
trough tor. The disabled check in torsocks could somehow catch this, if we
would knew the arch of the executable in advanced correctly (which we don't,
so far). If we can make sure, that LD_PRELOAD would stop executing, if the
library cannot be found.
e.g. I install libtorsocks:amd64 and wget:i386 I get:
$wget -O- -4 icanhazip.com
XX.230.187.XX
$ torsocks wget -O- -4 icanhazip.com
ERROR: ld.so: object 'libtorsocks.so' from LD_PRELOAD cannot be preloaded
(cannot open shared object file): ignored.
[...]
XX.230.187.XX
[...]
(installing libtorsocks:i386 fixes this)
On the other side, this does not got worse; currently torsocks will print
a different error see #902792 but still execute the binary without tor. So this
safety check doesn't help here (and btw. installing libtorsocks:i386 does not
fix this issue by itself you also need to call /usr/bin/i386-linux-gnu-
torsocks).
#902792 https://bugs.debian.org/cgi-bin/902792
This is an unfortunate failure mode, but yeah at least not worse than
the current state.
I was thinking about whether the torsocks script could try harder to
detect this case, e.g. by itself checking what arch binary is being run
and whether the corresponding library exists, but this would add a fair
bit of complexity and would still miss cases where the target binary
spawns more processes, possibly of different archs (e.g. `torsocks bash
-c "wget ..."`)
Regards,
hefee
___
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-le...@lists.torproject.org
-Jim
___
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Proposal 364: CreateOnehop handshake to replace CREATE_FAST
https://spec.torproject.org/proposals/364-create-onehop.html This proposal describes a successor to CREATE_FAST that permits circuit handshake extensions. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! -- Nick ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Proposal 363: Required/recommended protocols for onion services
https://spec.torproject.org/proposals/363-required-protovers-and-hs.html This proposal describes an enhancement to how we use subprotocol versioning in the consensus to advertise recommended and required subprotocols for running and connecting to onion services. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! peace, -- Nick ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] ORB - Onion Reply Block
Hi gentlemen, I would like to introduce you to pluto an smtp relay wich is using ORBs and would like to know your thoughts. https://githib.com/Ch1ffr3punk/pluto I post it here, because on the regular Tor forum it did not yet received any attention, in form of replies. Best regards Stefan ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Re: ORB - Onion Reply Block
Sorry, typo. https://github.com/Ch1ffr3punk/pluto Regards Stefan On Tue, Jun 3, 2025 at 3:43 PM Stefan Claas wrote: > > Hi gentlemen, > > I would like to introduce you to pluto an smtp relay wich is > using ORBs and would like to know your thoughts. > > https://githib.com/Ch1ffr3punk/pluto > > I post it here, because on the regular Tor forum > it did not yet received any attention, in form of replies. > > Best regards > Stefan ___________ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] New idea
Hi tor, I wanted to contact you about an idea I want to share with you. My idea is making all the original volunteers (who were in the project since the project begun) run a new relay, it’s like some sort of shield. And no one else other than the volunteers can make that shield node. The tor client is hardcoded to connect to one of the shields the volunteer is running, then the shield connects to the guard then middle then exit. It improves anonymity by hiding the IP address of a user from the guard because law enforcement can make relays too. And since the client will only connect to the shields provided from the volunteers there’s no way that law enforcement or any criminal can see someone’s IP. And for people in censored countries volunteers should also run shields that obfuscate network traffic so ISPs wont catch people trying to connect through tor. Tor browser would become slower but more anonymous. And that’s my idea, I hope you guys are safe and goodbye. ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Re: New idea
Hey again, just to be clear: I am not an official developer, but decided to give my thoughts anyway. If you require advanced security, look into the Vanguards project and it's detections for "abnormal" traffic / cells - it is mostly designed for hidden service operators, however clients can use it too :-) All the best, George On Thursday, July 17th, 2025 at 5:11 AM, Khaled Roomi wrote: > I got it, thank you George! > > > On 17 Jul 2025, at 6:26 AM, George Hartley hartley_geo...@proton.me wrote: > > > > Hey, > > > > Thanks for sharing your idea. > > > > That said, there are a few big issues with your proposal: > > > > 1.) Centralization of trust: Giving a fixed group of “original volunteers” > > special relay status adds centralized points of trust and failure. Tor has > > always aimed to avoid that — no single group should be in a position to > > de-anonymize users. > > > > 2.) The concept still exposes the IP somewhere: Replacing the guard with a > > “shield” doesn’t really solve the problem — it just moves it. The shield > > would now see the user’s IP instead of the guard, so we’re back to the same > > trust issue, just in a different spot. > > > > 3.) "Hard-coded" nodes are risky: If we hard-code a set of shield nodes, > > they become easy to block or target. And if any of them go down, users > > could lose access or hidden services could get de-anonymized. > > > > 4.) More latency: Adding an extra hop (shield → guard → middle → exit) > > makes the whole system slower and more complex, without clear benefits to > > anonymity. > > > > In a way, using a Snowflake bridge already does this according to my > > knowledge, as long as it is running as a Firefox plugin (which then proxies > > traffic to the "guard"). > > > > 5.) Exclusion and scalability: Restricting shield operation to only a small > > historical group doesn’t scale well and could create unnecessary > > gatekeeping. It also means we’d be relying on fewer people, which weakens > > the network. > > > > 6.) As mentioned above with Snowflake, censorship resistance is already > > handled elsewhere. > > > > Obfuscation for censored users is already addressed through pluggable > > transports like obfs4, meek, snowflake, etc. These are designed to be > > dynamic and hard to detect — hardcoded nodes would be a step back. > > > > In short: it’s a well-meaning idea, and the concerns behind it are valid - > > but the approach would likely introduce more problems than it solves. The > > current design of Tor reflects a lot of hard lessons about trust, > > decentralization, and threat modeling that we’ve learned the hard way over > > the past few years. > > > > Thank you, > > > > - George > > > > On Wednesday, July 16th, 2025 at 11:45 AM, Khaled Roomi via tor-dev > > tor-dev@lists.torproject.org wrote: > > > > > Hi tor, I wanted to contact you about an idea I want to share with you. > > > My idea is making all the original volunteers (who were in the project > > > since the project begun) run a new relay, it’s like some sort of shield. > > > And no one else other than the volunteers can make that shield node. The > > > tor client is hardcoded to connect to one of the shields the volunteer is > > > running, then the shield connects to the guard then middle then exit. It > > > improves anonymity by hiding the IP address of a user from the guard > > > because law enforcement can make relays too. And since the client will > > > only connect to the shields provided from the volunteers there’s no way > > > that law enforcement or any criminal can see someone’s IP. And for people > > > in censored countries volunteers should also run shields that obfuscate > > > network traffic so ISPs wont catch people trying to connect through tor. > > > Tor browser would become slower but more anonymous. And that’s my idea, I > > > hope you guys are safe and goodbye. > > > ___ > > > tor-dev mailing list -- tor-dev@lists.torproject.org > > > To unsubscribe send an email to tor-dev-le...@lists.torproject.org > > > publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Re: New idea
Hey, Thanks for sharing your idea. That said, there are a few big issues with your proposal: 1.) Centralization of trust: Giving a fixed group of “original volunteers” special relay status adds centralized points of trust and failure. Tor has always aimed to avoid that — no single group should be in a position to de-anonymize users. 2.) The concept still exposes the IP somewhere: Replacing the guard with a “shield” doesn’t really solve the problem — it just moves it. The shield would now see the user’s IP instead of the guard, so we’re back to the same trust issue, just in a different spot. 3.) "Hard-coded" nodes are risky: If we hard-code a set of shield nodes, they become easy to block or target. And if any of them go down, users could lose access or hidden services could get de-anonymized. 4.) More latency: Adding an extra hop (shield → guard → middle → exit) makes the whole system slower and more complex, without clear benefits to anonymity. In a way, using a Snowflake bridge already does this according to my knowledge, as long as it is running as a Firefox plugin (which then proxies traffic to the "guard"). 5.) Exclusion and scalability: Restricting shield operation to only a small historical group doesn’t scale well and could create unnecessary gatekeeping. It also means we’d be relying on fewer people, which weakens the network. 6.) As mentioned above with Snowflake, censorship resistance is already handled elsewhere. Obfuscation for censored users is already addressed through pluggable transports like obfs4, meek, snowflake, etc. These are designed to be dynamic and hard to detect — hardcoded nodes would be a step back. In short: it’s a well-meaning idea, and the concerns behind it are valid - but the approach would likely introduce more problems than it solves. The current design of Tor reflects a lot of hard lessons about trust, decentralization, and threat modeling that we’ve learned the hard way over the past few years. Thank you, - George On Wednesday, July 16th, 2025 at 11:45 AM, Khaled Roomi via tor-dev wrote: > Hi tor, I wanted to contact you about an idea I want to share with you. My > idea is making all the original volunteers (who were in the project since the > project begun) run a new relay, it’s like some sort of shield. And no one > else other than the volunteers can make that shield node. The tor client is > hardcoded to connect to one of the shields the volunteer is running, then the > shield connects to the guard then middle then exit. It improves anonymity by > hiding the IP address of a user from the guard because law enforcement can > make relays too. And since the client will only connect to the shields > provided from the volunteers there’s no way that law enforcement or any > criminal can see someone’s IP. And for people in censored countries > volunteers should also run shields that obfuscate network traffic so ISPs > wont catch people trying to connect through tor. Tor browser would become > slower but more anonymous. And that’s my idea, I hope you guys are safe and > goodbye. > _______ > tor-dev mailing list -- tor-dev@lists.torproject.org > To unsubscribe send an email to tor-dev-le...@lists.torproject.org publickey - hartley_george@proton.me - 0xAEE8E00F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature _______ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Proposal 362: Update onion service proof-of-work control loop
https://spec.torproject.org/proposals/362-update-pow-control-loop.html This proposal suggests a new algorithm for onion services to use to select the suggested effort value for the proof-of-work algorithm. The existing algorithm has some weaknesses, mostly stemming from the fact that the same request sent at different points in time might have different effects on the new suggested effort. The proposed algorithm is based in a more fundamental analysis of the goals of the control loop. Please feel free to open tickets on GitLab, discuss in the tracking ticket, torspec#329, or discuss here. :w ___ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
[tor-dev] Re: About the key derivation algorithm used in the Control Port password authentication
On 01/03/2025 17.33, techmetx11 via tor-dev wrote: Are there any plans to revamp the algorithm for newer Tor versions? I don't think so. All the focus right now is on getting Arti into a state where it can replace all of Tor's current usage. Arti has just gotten an RPC layer that we hope to get feedback on from integrators. C Tor is in a development mode right now where we mostly fix things that are needed for the Tor Network (relays, and tooling around relays), and features/removal of features that makes it easier to implement our protocols for Arti. As the ControlPort is generally only used on local machines, I doubt this is something that we will want to fix. Cheers, Alex -- Alexander Hansen Færøy _______ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-le...@lists.torproject.org
Re: [tor-dev] [CRITICAL] DeepCorr Traffic Confirmation Attack
I have not read this paper thoroughly, and it definitely seems to make a significant contribution. But the concerns that you raise are not what is new, and I hope this message will reduce your sense of alarm. If an attacker is interested in a given user or onion service and can watch both ends of a connection, it is well documented that they can correlate with high accuracy and low false positives. And this was understood, if not yet experimentally validated, not just when we first made Tor, but for pre-Tor versions of onion routing. The issue discussed in the paper is to be able to look at (both ends of) _large volumes_ of traffic flow and be able do correlations with low false positives. I haven't had a chance to look carefully at the contribution, but even in this area the novelty is somewhat overstated, because IMO the authors understate the contributions of their reference [49]. Murdoch and Zielinski showed back in 02007 that an IXP could correlate quite well sampling only around 1/2000 packets. Somebody should idiot-check me, since I'm pulling those results from memory without looking (too busy today). Nonetheless, even if the numbers aren't exactly right, Murdoch and Zielinksi showed the ability to correlate at scale with low sampling. Again, I believe the paper being discussed substantially improves on [49] in many respects, but the basic idea that correlation at scale is feasible was not only understood but demonstrated sixteen years ago. HTH. On Tue, Feb 28, 2023 at 09:59:00AM -0300, Holmes Wilson wrote: > This attack looks especially bad for situations where both ends of the > connection are controlled by the attacker, so it seems really bad for > onionshare, ricochet refresh, Briar, and Quiet, at least when users are > communicating with others in the same country. 96% correlation after 900k > of data sent! That's just a few images or files. > > It probably would work again cwtch too at least if it was trained for that, > since while users might be connected to a server outside the attacker's > region of control, but the data flows would correlate since the cwtch > server is also just relaying data. > > Should all of these apps be using obs4 with IAT mode on? (The mitigation > recommended by the paper?) > > How meaningful is Tor's metadata protection for an app like Quiet, Briar, > or OnionShare given this attack, assuming most users are communicating with > others within a country that can mount such an attack? > > On Tue, Feb 28, 2023, 8:23 AM Guard via tor-dev < > tor-dev@lists.torproject.org> wrote: > > > Hi, > > > > I was just reading a paper on traffic confirmation attacks over here > > https://arxiv.org/pdf/1808.07285v1.pdf. This attack runs with the help of > > deep learning algorithm called DeepCorr. This attack can be run in a Five > > Eyes country or an authoritarian regime like Russia where companies are > > compelled to cooperate with the government making this attack plausible. > > The ISP and the website operators are the two endpoints for this attack. > > This attack was able to achieve a success rate of over 96% which > > represents a serious threat to Tor users in these regions. The paper also > > includes some countermeasures on how to defeat this method of traffic > > confirmation. > > > > Thanks. > > > > _______ > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > _______ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
