Re: [tor-talk] VPS provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This is a good start :) https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs Cheers! David Webmaster: > Can anyone suggest a vps provider that is friendly to tor hidden > services. This would not be for an exit node. > > ___ tor-talk mailing > list tor-talk@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJQYerZAAoJEELoaioR9I02m8UIAKFQbF6bOwRpCCALuuGBJBkW 7z4mnogPBj0fCK3oaadKLlWLlUPspFeV/amY4iAALCulzn7kc25PfxbMQ4Ndgzxm +4n78JhaWHuRisQOdnpJA74MaIeHDMkRHEhiebxQuuN2z1MCB+KGtmxHR6rZNR+M k92fItITHVk0xd2/pXpNNwMz7rXf0UhkBxoOjhavR+H8ig2UqLRjKL+CRRdQ1EzN redIOsNdiODOi16b4wW9WBLtJ6vBBjK/GKqyPX0ogh6b/M4JhUnYlZiyqYyQYRKe UDmYh/LSuDquES3ae0dNh/5VmzT1EHp3eMaT3+0EDbEXnQm43jx2H5qA6n57zCA= =0K96 -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Tor exit node IPv6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi everyone, I'm looking to run a Tor exit node but IPv6 only. Anyone do/did that and got useful information about that? I don't know the state of the Tor network using IPv6. Is there some statistics somewhere about the number of nodes (or estimation) ? I can't find anything on metrics.torproject.org. Thanks everyone! David -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJQab/3AAoJEELoaioR9I02yhsH/RvAg9HEvXxK5U33wI3R0cvI hGKc6RpWmkGQwJv/8eL9MLipdy+VIJMmrEg+jwgicJ+GNHkiMpFbXC+a9vsGv98J n9W4WELN7Xui947B4Onz5Rwn+zV0Vfp2rifJM/gZQVADBn9Q8liqQoaMEKl/cF9y kq0NSlv4rHOhqC6wCECWdsrcnh3VkR4CZC0DlTJa1L7syx47bhs/UC/BKR5UiuXf hgq422MO+QnAjr/qzbywM4LaU3eOJnpdZejdah88hElDPFsvQjXf15FqmwOryHc2 MDPfVxnPT6WdSIGGO2u1TsEm0r2IhOi+Fqh/7N61/ymzwF0HKsatvR0Uj5GCFcs= =GOY0 -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor exit node IPv6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Oh well that answers it! :) I would really love to contribute more code to Tor but it's... like anything else.. a time issue :). However, I can surely help test the bridges in the meantime! Thanks! David Roger Dingledine: > On Mon, Oct 01, 2012 at 12:08:27PM -0400, David Goulet wrote: >> I'm looking to run a Tor exit node but IPv6 only. >> >> Anyone do/did that and got useful information about that? >> >> I don't know the state of the Tor network using IPv6. Is there >> some statistics somewhere about the number of nodes (or >> estimation) ? I can't find anything on metrics.torproject.org. > > https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6 > > IPv6 bridges and guards work, but exiting isn't implemented yet. > > (You could help. :) > > --Roger > > ___ tor-talk mailing > list tor-talk@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJQacNjAAoJEELoaioR9I02yVUH/RxgsaP6mqJWAw0kloUBTN2u aITFQzhVBx2qToRvQosrMAKxpdjuRPgssZ2M+TwxIupz7rlas6GD4dI+sKoaHQK0 vvJnmhZaB9D3Ko1WXBDpqZt3Etr8x6wyx1kWIaxbIqUCa3HQTvLJX1sg119cAukM aY3f3wudJisGs0koRuOvC9afgc+Xg+9d9dVdPMBtmwqv3DiQeqheaVgzzjHIhTYa PFXN145YVsCEKzeBzOuG9e3AJtsZoFjh3xP2vwZfTtaNuvcA9AaKSW1Qzw8MFZ0E SOb000sUMNBMLOJOB0kd6ETCSiewuW/lGxxc7qVsiIVDRrOlUgKsIKrsS5yjKnY= =rcAD -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] News from Iran
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 NotDashEscaped: You need GnuPG to verify this message Just a quick note on China and IPsec. Less than a month or so, I know and confirmed that a certain company inside China still uses Cisco IPsec to communicate with their outside division (EU). I can't name the company here but it is a big one. I worked on that project a while ago and checked recently with a colleague which confirmed me that the tunnel is sill in operation. The question now is if it has ties with the government for that kind of services or not. (bribe, influence, that I don't know). Thanks! David and...@torproject.is: > On Wed, Oct 03, 2012 at 05:41:05PM -0400, and...@pdqvpn.com wrote > 1.0K bytes in 34 lines about: : IPsec is trivially easy to block. > Most countries do it at the edge with simple port based firewalls. > > Yes, but not sure they actually block it. As of 6 months ago, > china ignored ipsec. > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCgAGBQJQbZLEAAoJEELoaioR9I02rxQH/0UrC+KCnd7+P7jJsHJJ1RNk 914JKiwV5+A4OPryvbTqmpnmvwqTughPqYTAHQSFYLP9lo2oS1I7YWA61JRiVQUR sjG2R1hBYrTfKAPXO6vASGHHOsnnES5NWa86kEHzQvUh6KFdDx9OtrqF8F/S/Btr VGMess1zYdQb4qvvTs3r+pgP3TDMIpeqREsN12gZ+NQ3crkDQF6rUixpbp2lf8i1 Vw8KrPec+ov7/JNMITvaL4bSM1nnnvjAq8F4cqkHslgS/cYNEbcG5JcuYAN+YXng agskgi+eEzmfr8XMHWd354SXhVnMpM4m1ihrE+Gh6ExZfMzpt2qw58q3mz9rtgk= =fqcl -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Torsocks 2.x status report
Hi everyone! Took me a while to do it but there it is! For those not following torsocks development, this is a status report of the project. As of April 4th 2014, the release candidate 7 was released. With that release, the main code is now on torproject.org which is now the official upstream of the project. https://gitweb.torproject.org/torsocks.git My Github repository[1] is now a mirror and all tickets from the tracker have been moved to trac.torproject.org. We are still looking for some more Signed-off or/and Acked-by volunteers that want to have a look at the code. With that, 2.0 stable will be released and from there we'll start adding features! :) Thanks to intrigeri and Lunar, you can find the new version in Debian experimental by now. https://packages.debian.org/experimental/torsocks I plan to update the Tor wiki[2][3] with that new version, create a FAQ and a blog post explaining the Why/How of torsocks 2.0. Finally, the old page should be close soon (hopefully) thus moving everything back to torproject.org. https://code.google.com/p/torsocks/ That's about it, again please test and review it to help out :). Cheers! David [1] https://github.com/dgoulet/torsocks [2] https://trac.torproject.org/projects/tor/wiki/doc/torsocks [3] https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] OTFC IRC issues - new Tor friendly IRC network?
On 02 Jul (04:03:20), Matt Pagan wrote: > > BlueStar88: > > 37lnq2veifl4kar7.onion:6697 is up and running fine. > > > > > > When connecting with `screen torsocks irssi -c 37lnq2veifl4kar7.onion -p > 6697` I get the error message: > > [(status)] [Jul 01 22:33:27] WARNING torsocks[26459]: [connect] > Connection to a local address are denied since it might be a TCP DNS > query to a local DNS server > > So that irssi reports > > Irssi: Unable to connect server 37lnq2veifl4kar7.onion port 6697 > [Operation not permitted] Irssi has a special way of resolving DNS query. It spwans a different process to resolve and then sends back the result to the main thread that connects to the server. Using an onion address with irssi and torsocks is not possible at the moment because we need a shared memory region between processes to handle the "DNS resolution" of .onion. I have a patch for that in a dev. branch but it's highly experimental for now and for some reason does not work on OS X. Once we have a stable 2.0 released, I will give it more work so it can handle multi process DNS resolution. Cheers! David > > Is this a misconfiguration on my part, or a bug with torsocks? It seems > that the old torsocks versions 1.1 and 1.2 had some similar > issues[0][1][2][3], but I'm not sure how much of that code is reused or > fixed in the 2.0 rewrite... > > [0]: https://code.google.com/p/torsocks/issues/detail?id=32 > [1]: https://code.google.com/p/torsocks/issues/detail?id=34 > [2]: https://code.google.com/p/torsocks/issues/detail?id=35 > [3]: https://code.google.com/p/torsocks/issues/detail?id=36 > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] [RELEASE] Torsocks 2.0.0 stable
Hi everyone! Following the discussion of bug #10007[1], this is the *stable* release 2.0.0 for torsocks. Nothing major went in since -rc7, see the change log below. 2014-08-11 torsocks 2.0.0 * Fix: compilation issue on Debian kfreebsd-i386 * Fix: add LICENSE file to repository * Fix: add compilation requirements to README.md Again, as usual, and forever! *please* code review, test and most importantly report any issues. Contribution ftw! :) Thanks to everyone! Git: https://gitweb.torproject.org/torsocks.git Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.0.0.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.0.0.tar.bz2.asc) Cheers! David [1] https://trac.torproject.org/projects/tor/ticket/10007 signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor over SSH (torsocks) (?)
On 16 Feb (00:27:40), James Murphy wrote: > On 02/15/2015 03:22 PM, blo...@openmailbox.org wrote: > > I want to login to my VPS over SSH. > > > > Is torsocks still a safe way to do this? A lot of the > > documentation (such as it is) is several years old. > > > > > > I would also like to know this. SSH hidden service setup and use are > easy with torsocks. > > /etc/tor/torrc > > HiddenServiceDir /var/lib/tor/ssh_service/ > HiddenServicePort 22 127.0.0.1:22 > > Then > > torsocks ssh user@xxx.onion > > works like a charm. > > Can anyone comment on security of torsocks? (So yeah I sent that a week ago and didn't notice that I used the wrong email address for the list so here it is) Torsocks was rewritten alost from scratch due to design issues and the code was unmaintained since 2009. This new version is 2.0 and is now packaged by most Linux distros. https://people.torproject.org/~dgoulet/torsocks/ git: https://gitweb.torproject.org/torsocks.git Now, that effort did improved the safety of it I would say quite a bit. I won't go in the technical details but it's better and maintained now. That being said, know this, torsocks is a best effort, it's not a silver bullet and it's "easy" to design an application that will bypass torsocks. However, you can be confident with a bunch of stuff such as ssh, wget, netcat, etc... It's extensively used with those applications on a daily basis. Tails and Whonix for instance rely on torsocks for some applications (note that their firewall gives them extra protection). I know that people are using torsocks with postfix and it works well. I would be happy to detail technical details of torsocks if someone would like to, maybe a blog post? Cheers! David > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] 100-Foot Overview on Tor
On 06 May (19:28:38), teor wrote: > > > > Date: Tue, 5 May 2015 18:49:39 -0500 > > From: Tom Ritter > > > > On 5 May 2015 at 07:53, Fabian Keil wrote: > >> Great. > >> > >> A couple of comments (about v1.3): > > > > Thanks! I made the changes and put up a 1.4 > > > >> Page 141 and 142 seem to suggest that parsing strings is more > >> likely to be vulnerable than parsing binary data. Is that intended? > > > > No but mostly yes. It's more a surprise factor: when I tell people tor > > uses HTTP to upload and download things, they're not surprised - when > > I tell them it has its own HTTP server implementation that does all > > the parsing of the requests, they're much more surprised. I'm not > > saying tor's code is insecure (I put up a $bounty inside my company > > with my own money to anyone who finds a bug in it actually) - but > > implementing your own HTTP server is not a recommended action. :) > > > >> Is the source of the PDF available under a free license? > >> > >> I'm currently preparing a (German) presentation about location > >> hidden block storage and could reuse the HS-related parts: > >> http://chaos.cologne/Fahrplan/events/6653.html > > > > It's (now) http://creativecommons.org/licenses/by-sa/4.0/ > > > > As far as the sources well, I made it in keynote. Yes, I know I'm > > a bad person. I can export it as powerpoint, html, images, or pdf and > > send you any one of those five. (Or all of them.) > > Hi Tom, > > Some further feedback: > > Page 20: > Can you explain why you say that consensuses are valid for 24 hours, and not > 3 hours? Indeed, according to dir-spec.txt, see section "1.4 Voting timeline", there is an explanation. The current tor code actually randomize some of those values to be in a specific range that is not more than 3 hours (iirc). > > Page 113: > I think there are 3 relays between the client and introduction point, not 2. > In new_route_len(), each circuit with an endpoint chosen by another relay > gets an extra hop, and the hidden service chooses the introduction point, not > the client. > > I could be wrong about this - the path code has a few special cases that I > haven't quite got my head around. Yes you are right. Not only that but if the first introduction point fails (client side), the circuit is re-extended to the second intro point and so on until it works or the the maximum limit of 7 hops is reached. That's maybe a bit too deep to explain in the slides so I guess 4 hops Client <-> Intro is good enough. :) Tom, those slides are great! Impressive job! Thanks for this. David > > teor > > teor2345 at gmail dot com > pgp 0xABFED1AC > https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 > > teor at blah dot im > OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 > > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] "Torifier" for Windows
Hi, I've been working on a re-engineering of torsocks recently and I would really like to support Windows natively! However, since I'm far from a Win. developer, some important portability issues need to be address. On *nix system we LD_PRELOAD the program thus hijacking the necessary symbols to make sure all your TCP and DNS traffic goes through Tor. On Windows, I'm a bit clueless on how to proceed but for that I'm really looking for contributors to help. :) A goal of mine would be to have a "right click" on a program's icon feature, point to "Use with Tor" and launch the application with torsocks. If anyone is interested in helping with torsocks and Windows, that would be really great! Thanks! David mancha: > Hello. > > Is there a Tor Project sanctioned method to "torify" > applications on Windows? > > On systems such as Linux there are wrappers like torify > and torsocks. Windows does have some functional pseudo > equivalents like FreeCap and other proprietary/closed > applications. > > I am wondering if anyone has worked on something that can > torify command line (say via Cygwin) or if the Tor project > has a recommended method for torifying applications that > lack native SOCKS support. > > Cheers. > > --mancha > > ___ > tor-talk mailing list > tor-talk@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: OpenPGP digital signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] torsocks/usewithtor only for .onion?
I guess that could be an option useful to add to torsocks for that. As of now, with the current version of torsocks (1.3.x), you can't. We could add something like "torsocks --only-onion" ... ? Thanks! David Moritz Bartl: > Hi, > > Is there any way to "torify" applications so they can reach .onion URLs, > but everything else does not use Tor but connects directly? > signature.asc Description: OpenPGP digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Torsocks 2.0.0-rc1 release
Greetings everyone! Two months ago I sent an email [1] to the tor-dev mailing list explaining some important issues with torsocks. I proposed myself to do a complete rewrite for the reasons detailed in the email. I've released today the first release candidate for a 2.0.0 version. https://github.com/dgoulet/torsocks Package: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc1.tar.gz I'm asking the community for feedbacks, testing, code review, optimization design and/or anything useful to help improve the project (even correcting the mistakes or improving any comments). The TODO file in the repository contains some needed features but that are not critical to the project for a beta release. Hopefully, with your help, we will be able to replace the current version with a better one, more tested, more hardened and more portable!... and maybe with a more meaningful name :). What is really needed right now is OS X and BSD testers. I did my best to only use POSIX standard and making sure that libc calls are the same on all platforms but I was not able to test it on other OS other than Linux so they might some issues. There is *no* Windows support but again that would be amazing if someone could port it. Again, please contribute and help this very useful tool getting better! I encourage you all to use tor-dev mailing list for any development issues. I'm also on IRC in #tor-dev as "dgoulet". You can also find me on OFTC, freenode and indymedia servers. Big thanks to everyone! Using it is testing it! :) Cheers! David [1] https://lists.torproject.org/pipermail/tor-dev/2013-June/004959.html signature.asc Description: OpenPGP digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] [RELEASE] Torsocks 2.0.0-rc2
Greetings everyone! After a week or so, the release candidate 2 is now out after receiving various contributions for BSD and OS X support. A quick note. Please use the Github bug tracker for any issues and *not* trac.torproject.org. Until this code base is accepted as a potential replacement for the old version, please use the current repository issue tracker. Here is the ChangeLog: 2013-09-02 torsocks 2.0.0-rc2 * Fix: remove FAQ file from Makefile * Fix: remove out of date and inaccurate FAQ * Tests: add connection object unit test * Fix: Improve README file * Tests: add onion pool subsystem unit test * Use extern for tsocks_libc_* in torsocks.h * Define LIBC_SYSCALL_ for OS X * Make sure __darwin__ is defined * Fix: explicitly ignore fileno return value * Use AC_CHECK_FUNC rather than AC_LINK_IFELSE. * Find out if we really need libdl. * Define LIBC_SYSCALL_ for FreeBSD. * Use SYS_ from . * Include for AF_INET*. * Use getsockname(2) for finding out socket address family Please continue to test, review and contribute it! :) Tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc2.tar.gz Big thanks to all contributors for that release! Cheers! David signature.asc Description: OpenPGP digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [RELEASE] Torsocks 2.0.0-rc2
On 23 Oct (06:11:59), adrelanos wrote: > Lunar: > > David Goulet (2013-09-02): > >> After a week or so, the release candidate 2 is now out after receiving > >> various > >> contributions for BSD and OS X support. > >> > >> A quick note. Please use the Github bug tracker for any issues and *not* > >> trac.torproject.org. Until this code base is accepted as a potential > >> replacement > >> for the old version, please use the current repository issue tracker. > >> […] > >> Please continue to test, review and contribute it! :) > > > > For those too lazy to build torsocks manually, I have just uploaded an > > updated package to Debian experimental [1]. > > > > David has also opened #10007 [2] so we can finally bless the new > > codebase after more review. Please contribute if you can. > > > > [1] http://packages.qa.debian.org/t/torsocks/news/20131022T212043Z.html > > [2] https://bugs.torproject.org/10007 > > Hi! > > Thank yo for doing this. > > Will packages for i386 be build? > > I failed to build them from your source package, but perhaps you're not > yet at this point. There is a patch pending to be merged for i386 support that needs to be tested. The libc syscall values is kind of tricky on Linux x86. Feel free to help and test it :). https:/ /github.com/dgoulet/torsocks/issues/11 Also, any issue with that torsocks version, please open a ticker to the github bug tracker since this code is not part of the torproject yet. Thanks! David > > Best, > adrelanos > > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [RELEASE] Torsocks 2.0.0-rc2
On 05 Nov (20:44:08), adrelanos wrote: > Lunar: > > For those too lazy to build torsocks manually, I have just uploaded an > > updated package to Debian experimental [1]. > > Given that David said he plans to discuss a new name for torsocks > soon... And also to keep compatibility with existing scripts... > (torsocks changed a lot, config files are no longer compatible) Yah that's an issue that needs also to be discussed. Right now, this version of torsocks breaks the compatibility with the configuration file. I thought of keeping the old one but then I just told myself that considering a complete rewrite, let's take the opportunity to change that conf. file and do it right (and more Tor centric). It might not have been a good idea in the end but I'll let the community judge that and it's totally possible to revert that. > > To make a clean transition from torsocks to , > wouldn't it be better not to replace torsocks in Debian with the rewrite? > > I think the new package could enter the usual > experimental -> sid -> testing and the old torsocks should just be > removed from testing at some point (reason: dead upstream, superseded by > ). In terms of new naming, I would personally *love* that but we have to be careful with package that depends on torsocks and one comes into mind, "parcimonie". So, if we decide that a new name is a good idea, packaging needs to consider the transition and possible breakage. Cheers! David > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] [RELEASE] Torsocks 2.0.0-rc4
Hi everyone! After a big code review from Nick and help from a lot of people contributing and testing, this is the release candidate 4 for the new torsocks. Hopefully this is the last stretched before pushing this effort upstream but for that we need help with code/documentation review (again) and of course more and more testing! Multiple Signed-off on the code would be great so please go at it, ask questions, contribute! and let's make this new Torsocks awesomer! :) Some pointers on critical part of the code. --> src/lib/connect.c and close.c --> src/lib/getaddrinfo.c and gethostbyname.c --> src/lib/torsocks.c Also see the configuration file that has changed. --> doc/torsocks.conf If you are on OS X or/and BSD, please help make it work on those platforms. It's quite easy to break compatibility thus help make sure we didn't break it up :). https://github.com/dgoulet/torsocks.git Tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc4.tar.gz Big thanks to all! David signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] [RELEASE] Torsocks 2.0.0-rc5/6
Hi everyone! Here is the release candidate 5 *and* 6 for Torsocks 2.x. Unfortunately, right after the release 5, I've noticed a critical issue that made the new allow inbound option misbehaved quite badly so I'm immediately releasing rc6 containing that fix. Basically, you can ignore rc5 if you prefer. Sorry for that! A new option has been introduced to allow inbound connections (that were previously blocked in rc4). The torsocks.conf new option is "AllowInbound 0|1" set to 0 by default meaning listen/accept is *blocked* for remote connections only so the localhost is *alway* allowed. This fixes the "ssh -L/-D" use cases to open a listening socket. Again, *by default* any localhost socket will work so this example out of the box should work properly: $ ssh -D8080 yourserver.com You will notice a "listen: Operation not permitted" with the above command because by default ssh tries to connect to IPv6 localhost but fail somehow. I'm aware of the issue but will need much more investiguation to fix but it's not a show stopper. Furthermore, whois was not working because fclose() is used to close the socket and torsocks was not tracking that call thus failing to see the close connection. This was NOT triggering any leak but whois was simply not working. This has been fixed which is an important use case for Tails. Here is the change log for both versions. 2014-03-17 torsocks 2.0.0-rc6 * Fix: set addr len for getsockname in accept * Fix: use socket fd and NOT sockaddr in accept 2014-03-17 torsocks 2.0.0-rc5 * Fix: strict aliasing in library * Add fclose() support * Fix: add torsocks.conf option type * Add option to allow inbound connections * Fix: handle NULL node in getaddrinfo Again, as usual, and forever! *please* code review, test and most importantly report any issues. Contribution ftw! :) Git: https://github.com/dgoulet/torsocks.git (mirror: https://gitweb.torproject.org/user/dgoulet/torsocks.git) Github tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc6.tar.gz TPO Tarball: https://people.torproject.org/~dgoulet/torsocks-2.0.0-rc6.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks-2.0.0-rc6.tar.bz2.asc) Cheers! David signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] [RELEASE] Torsocks 2.0.0-rc7
Hi everyone! This is the release candidate 7 for torsocks 2.x. Nothing major, fixes and some code refactoring went in. From this point on, the upstream torsocks git[1] is now updated with that new code in the master branch but no stable release yet. With that, my github repository will become a mirror for a while but I will close the issue tracker after I move all the issues to the tpo trac. I will update the list next week on the current status of torsocks and what's next about this project. Here is the change log for this version. 2014-04-04 torsocks 2.0.0-rc7 * Fix: fix NULL dereference on error * Fix: memory leak in connect error path * Delete old source directory * Fix: nullify constant that might be undefined * Refactor the connect() code flow for clarity * Tests: add connect() test * Tests: add socket() test * Fix: socketpair() denied for INET[6] socket * Fix: socket() type check SOCK_STREAM * Fix: add autogen.sh to installation procedures * Fix: change TSOCKS_LOOPBACK bitness * Fix: support kfreebsd for mmap() Again, as usual, and forever! *please* code review, test and most importantly report any issues. Contribution ftw! :) Thanks to everyone! Git: https://github.com/dgoulet/torsocks.git (mirror: https://gitweb.torproject.org/user/dgoulet/torsocks.git) Github tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc7.tar.gz TPO Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.0.0-rc7.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.0.0-rc7.tar.bz2.asc) Cheers! David [1] https://gitweb.torproject.org/torsocks.git signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] [RELEASE] Torsocks 2.1.0
Hi everyone! This is the release for version 2.1.0 of Torsocks. Special thanks to Yawning that helped a lot with the new features, finding bugs and providing patches! Also, thanks to all contributors and users out there providing us with feedbacks! :) Changes that are worth mentionning: - Support for TCP fast open. - AllowOutboundLocalhost option allows torsocks to connect to a localhost address. - IsolatePID is a new option that will make torsocks set the SOCKS5 username and password automatically to provide isolation on Tor side. You can use this with the -i,--isolate command added or TORSOCKS_ISOLATE_PID env. variable. - Fix initialization phase when used with C++. - Way less annoying warnings of syscall being denied. Most of them were harmless so we let them pass now. - Multiple fixes! (see changelog below) Here is the change log for this version. 2015-05-27 torsocks 2.1.0 * Fix: socks5 resolve wasn't sending data correctly * Fix: wrong label when auth_socks5 fail * Move SOCKS5 auth in a seperate function * Send the SOCKS5 authentication for RESOLVE/RESOLVE_PTR requests. * Change IsolatePID password from 42 to 0 * Add automatic per process isolation (IsolatePID) * Ensure that torsocks initializes itself in the presence of C++. * Merge remote-tracking branch 'yawning/getaddrinfo' into getaddrinfo * Fix: indentation in getpeername test * Merge remote-tracking branch 'yawning/getpeername' * Add support for the various inotify routines when invoked via syscall(). * Support the eventfd2(2) syscall. * Support the various epoll routines when invoked via syscall(). * Handle accept4(2) when invoked via syscall(). * Fix getaddrinfo() to respect AI_NUMERICHOST. * Fix the broken getpeername() implementation. * Support certain Linux specific syscalls. * Allow TCP Fast Open clients go through tor * Test: support out of tree make check * configure.ac: avoid tests which have both -pie and -static * Fix error messages about setuid/setgid executables * Fix: switch back to a syscall whitelist scheme * Add AllowOutboundLocalhost. * Fix: syscall mmap for NetBSD * Fix: use getsockname instead of getsockopt to get socket family * Stop denying syscall() and add dangerous ones * Fix: typo in the listen macro declaration * Fix: improve getpeername to actually works * Fix: improve Unix socket passing detection * Test: add missing connection destroy * Test: possible double free in onion test * Test: fix memory leak in DNS test * Add accept as an accepted value through syscall() * Add cscope files to gitignore Again, as usual, and forever! *please* code review, test and most importantly report any issues. Contribution ftw! :) Thanks to everyone! Git: https://gitweb.torproject.org/torsocks.git Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.1.0.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.1.0.tar.bz2.asc) Cheers! David signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [RELEASE] Torsocks 2.1.0
On 27 May (18:14:37), Yuri wrote: > On 05/27/2015 12:19, David Goulet wrote: > >Hi everyone! > > > >This is the release for version 2.1.0 of Torsocks. Special thanks to > >Yawning that helped a lot with the new features, finding bugs and > >providing patches! Also, thanks to all contributors and users out there > >providing us with feedbacks!:) > > Hi David, > > Why didn't you merge all pull requests for the release? Hello! What other pull requests are you talking about? There are a couple of open tickets that need more time and thinking so I released this one because of the amount of fixes that has been accumulating. Cheers! David > > Yuri signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [RELEASE] Torsocks 2.1.0
On 28 May (02:38:04), Geoff Down wrote: > > > On Thu, May 28, 2015, at 02:29 AM, Geoff Down wrote: > > > > > > On Wed, May 27, 2015, at 08:19 PM, David Goulet wrote: > > > > > Tarball: > > > https://people.torproject.org/~dgoulet/torsocks/torsocks-2.1.0.tar.bz2 > > > (sig: > > > https://people.torproject.org/~dgoulet/torsocks/torsocks-2.1.0.tar.bz2.asc) > > > > > > > Which keyserver has your GPG key please? > > GD > > > > Found it at > x-hkp://pool.sks-keyservers.net > the same as the other Torproject keys - but there's no fingerprint on > the website for you. You mean on https://www.torproject.org/docs/signing-keys.html.en ? David > GD > > -- > http://www.fastmail.com - Accessible with your email software > or over the web > > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [RELEASE] Torsocks 2.1.0
On 28 May (14:54:55), Yuri wrote: > On 05/28/2015 06:25, David Goulet wrote: > >What other pull requests are you talking about? There are a couple of > >open tickets that need more time and thinking so I released this one > >because of the amount of fixes that has been accumulating. > > https://github.com/dgoulet/torsocks/pull/31 > https://github.com/dgoulet/torsocks/pull/32 Woa! I never saw those (or forgot about them?)... :( Sorry about that, I think my github notifications go into the spam folder for whatever reason... Also, I don't really use that repository, I think I do push the upstream code there by default but that's about it. Next time, you should use trac.torproject.org and open a ticket there for anything you want to fix on Torsocks. I go over them before a release. Thanks! David > > Yuri signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Hidden Service Scaling Summer of Privacy Project
On 15 Jun (18:28:42), Allen wrote: > Hi Donncha, > > One thing I think I'm seeing is that if I restart the tor process on a hidden > server, it chooses new introduction points and any clients that have a cached > service descriptor cannot access the hidden service until the cached > descriptor expires. This leads to an apparent service outage for those > clients. > > Does that correspond to what other people see when operating hidden services? FYI, we just discovered that this morning: https://trac.torproject.org/projects/tor/ticket/16381 This has been flagged as a major issue so we hope to resolve this asap. Cheers! David > > If that is the problem, the solution might be either that the tor proxy > client immediately expires a cached hidden service descriptor after failing > to reach the service, or that the tor process on the hidden server remembers > its introduction points so it can pick them back up when it restarts. > > Thanks, > > Allen > > > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] single entity running >36% exit probability with 5 relays? scary.
On 10 Dec (19:04:02), nusenu wrote: > take a look at the "e_prob" column: > > https://github.com/nusenu/tor-network-observations/blob/master/2015-12-10_relay-families.txt > > > How did he manage to get such a high consensus weight > (~10x ipredator's cw)? > > > > these four 0.2.7.5-dev relays were first seen on 2015-12-10 04:00:00 > are down since a few hours now > https://atlas.torproject.org/#search/contact:robgjansen Hi! This morning I noticed a huge spike in the estimated exit probability per continent graph and network capacity graph: http://ygzf7uqcusp4ayjs.onion/tor-health/tor-health/index.html After a bit of investiguation turns out 3 new relays were advertising a HUGE bandwidth. I contacted the person (it's a known Tor researcher at NRL) and he realized they were mis-configured advertising way too much bw. It should be fixed soon hopefully but they are 3 real exit nodes. However, the humongeous weights are concerning since they were very "young" relays in the lifetime of a relay so it worth investiguating and thinking if this is normal or maybe a bug? Cheers! David > > > btw: thanks for setting an apparently proper myfamily config. > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Does Facebook Onion Work?
On 17 Feb (22:10:44), Sebastian Hahn wrote: > Hi blobby, > > > On 17 Feb 2016, at 21:17, blo...@openmailbox.org wrote: > > Does Facebook still provide an onion link? > > > > Because I've tried https://www.facebookcorewwwi.onion/ and I get a > > neverending loop in which the site loads and loads and loads... > > > > Any ideas? > > the correct address is https://facebookcorewwwi.onion/ - never use > www. in onionland. Hrm, actually the subdomains are important for Facebook. They will redirect you to the www. if omitted and since the SSL certificate is an EV wild card, it can take anything as subdomain. So with that, they can easily regex the URL once it arrives to the HS and send it to the right place internally using only the subdomain. All the languages for instance are subdomain "fr-ca.", "it-it.", "en-us.", etc... Cheers! David > > Cheers > Sebastian > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Massive Bandwidth Onion Services
On 19 Dec (09:04:46), Allen wrote: > AFAIK, HiddenServiceNumIntroductionPoints >= 3 is also for the benefit > of the client, so if intro point #1 doesn't work for the client, it > can try to connect at intro point #2, and then finally at intro point > #3 before giving up. So let's say my Tor client looks up your Tor > hidden service descriptor and attempts to connect at intro point #1 > and that fails. What would/should it do at that point? Give up? Good point! To clarify here the client behavior in that case Your tor client will add that intro point in a "failure cache" which will stay in there for 5 minutes (yeah... possibly way too high! ticket #17520) and then if you have a descriptor that has *no* more usable intro points (that is they are all in the failure cache), a fetch will be triggered on the remaining set of HSDir you haven't lookup for a hopefully new descriptor. Then that new descriptor intro points are checked agains that failure cache and will be used accordingly. So, in this case with 1 single intro point that fails, the client will ask another HSDir for a new descriptor and so on... More comment below. > > On Mon, Dec 19, 2016 at 5:47 AM, Alec Muffett wrote: > > As an aside, this is what I am currently using as a daemon config. > > Comments welcome. > > > > I'm trying not to use Guards because again it would be rude to hammer them > > with vast data flows when instead the pain can be spread around a bit more; > > given that my target deployments are unlikely to be truly anonymous (eg: > > Facebook) this isn't much of an anonymity issue. > > > > > > $ more /home/alecm/master/halfagig/hs6.d/config > > DataDirectory /home/alecm/master/halfagig/hs6.d > > HiddenServiceDir /home/alecm/master/halfagig/hs6.d/ > > # HiddenServicePort 19 localhost:8506 # chargen, eventually > > HiddenServicePort 80 localhost:10506 > > HiddenServiceNumIntroductionPoints 3 # <--- maybe 2 or 1 here? Fun fact, I believe this is a bug 0 intro point is actually suppose to be allowed as it is an easy way to "disable" your service and a valid case as well. Not only that, but the documentation does NOT specifies anything about a lower limit... I just opened: https://trac.torproject.org/projects/tor/ticket/21033 > > LongLivedPorts 19,80 > > # > > CircuitBuildTimeout 60 > > LearnCircuitBuildTimeout 0 > > PredictedPortsRelevanceTime 0 > > RendPostPeriod 37 minutes Ok so here is the thing. I would put some "advisory" on your setup here as default values are changed for the descriptor. Because of design issues in the current HS protocol, any HSDir can learn the amount of introduction points you have meaning if you change it from the default value, you'll increase the chances of being more identifiable as you "don't look like the others". Second, same occurs with modifying that RendPostPeriod from the default value of an hour to a custom time time. It makes you a bit more noticeable because you have a different behavior then anyone else. (And possibly some effect of disabling LearnCircuitBuildTimeout). Those do not lead to an "automatic deanonymization" but lets say they won't help. However, in the case of a single onion service (just release stable few minutes ago :D), this is really great! Thanks Alec! David > > SocksPort 0 > > UseEntryGuards 0 > > UseEntryGuardsAsDirGuards 0 > > -- > > tor-talk mailing list - tor-talk@lists.torproject.org > > To unsubscribe or change other settings go to > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Not comfortable with the new single-hop system merged into Tor
On 20 Dec (23:38:43), hi...@safe-mail.net wrote: > I just think that this new single-hop system should have been reserved for a > different Tor source/installation, dedicated only to non-anonymous hidden > services, not merge it with the regular Tor software. And this for security. > > I once witnessed a software (non-Tor related) that had a special function > which was disabled by default, but was accidentally enabled due to a bug > that occured during special circumstances, causing big trouble for some. In > this case it caused a big money loss for some, but with the Tor software we > are talking about the lives and wellbeing of humans. > > How do I know that my hidden service is really running anonymously, and not > with just 1-hop, besides just trusting the config defaults? > > Please prove me wrong. I'm just concerned here, and just want some feedback. > Thanks for understanding! Hi Hikki! Thanks for your input, this is a very legitimate concern and I will try to address it as much as I can from my Tor developer perspective. First, we had many discussion about the naming of this configuration option because we were quite worried that it would be too easy to make a mistake or enable it because some configuration posted online on a pastebin was setting it on. This is why we want with the need for _two_ options where one is VERY obvious that you are going to lose your anonymity. HiddenServiceNonAnonymousMode 1 Second, once this is set, multiple things are disabled on your tor because of safety issues. *All* client side services such as the SocksPort have to be disabled because that option means that your _entire_ Tor instance goes into non anonymous mode for hidden service. This is too much of a risk to let users run client side functionnalities. Tor2Web (which I personally dislike) is still an option for client to lose their anonymity and thus reach an hidden service much faster but it's something you have to compile in as a safety measure which Tor Project does not distribute compiled in. Third, with a single onion service, you can NOT run a normal onion service on the same tor instance again for security issues. Once you turn your tor instance in the "non anonymous mode", it will stay that way unless you mangle quite a few things which is NOT obvious! You can also check in your onion service directory that this file is NOT present "onion_service_non_anonymous" which is put there if tor is configued for single onion service. Now to your concern of "What if we have a bug in the code that actually makes all new onion service become single onion service?" To be honest, that is the uncertainty of computers and programming that will probably never go away. It will _always_ be possible that something goes bad in the code. We have MANY other features and functionnalities in Tor that if they go bad, it will be worst then having your service become an onion service. But, this is where I guess people using Tor have to trust a bit the Tor Project that we did our best for the safety of our users which is the number *one* priority at all time for us, period. On a side note: With the next generation onion service (we hope by mid-2017 so ~6 months), every onion service will advertise in its descriptor that it *is* a single onion service and we hope to make the circuit viewer in Tor Browser show that when visiting a single onion service. I hope this help answer some of your concerns! Thanks! David > > -Hikki > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] privacy of hidden services
On 21 Dec (19:37:13), Aeris wrote: > > Would anyone outside of myself and those two > > people be able to determine the onion address > > Yes. Your onion address is published on a DHT, hosted accross all nodes with > HSDir flag. Some bad behaviouring relays try to enumerate all onion addresses > by massive HSDir node creation to fetch different part of the DHT each time. Quick note that our next version of onion service (v3) will mitigate this harvesting as the HSDir and Introduction Point won't be able to learn the onion address. But yes, currently this is a weakness in the protocol. > > > or monitor activity related to the hidden service such as HS descriptor > uploads and downloads from directory servers, or connection attempts via > > introduction or rendezvous points? > > Yes too. HSDir node and rendez-vous points can monitor HS usage, because > HSDir/RdVPoint usage for a single HS is correlated to this HS usage. Wait. Rendezvous Point (RP) do *NOT* know the onion service identity unless you do some sort of circuit fingerprinting or HSDir correlation attacks. But, assuming not doing such an attack, RPs don't have the information. It can only track how much traffic is going through an onion service circuit without knowing which service it is. But, the Introduction Point (IP) does! so it can monitor how many connections are made to the service using the IP and identify the .onion. Although, it won't get them all as a normal descriptor has 3 different IPs but it can extrapolate easily. > > > Would it make a difference if the hidden service used basic or stealth > authorization? > > AFAIK, no. Auth for a HS is only to forbid unallowed client to connect to it, > but doesn't change the way HSDir and RdVPoint are handled. Correct except not the RdVPoint but the Introduction Point will be different for stealth authorization as it is a descriptor per client authorization. Cheers! David > > Regards, > -- > Aeris > Individual crypto-terrorist group self-radicalized on the digital Internet > https://imirhil.fr/ > > Protect your privacy, encrypt your communications > GPG : EFB74277 ECE4E222 > OTR : 5769616D 2D3DAC72 > https://café-vie-privée.fr/ > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Not comfortable with the new single-hop system merged into Tor
On 23 Dec (00:03:00), Ivan Markin wrote: > David Goulet: > > On 20 Dec (23:38:43), hi...@safe-mail.net wrote: > >> I just think that this new single-hop system should have been reserved for > >> a > >> different Tor source/installation, dedicated only to non-anonymous hidden > >> services, not merge it with the regular Tor software. And this for > >> security. > > > Now to your concern of "What if we have a bug in the code that actually > > makes > > all new onion service become single onion service?" > > > > To be honest, that is the uncertainty of computers and programming that will > > probably never go away. It will _always_ be possible that something goes bad > > in the code. We have MANY other features and functionnalities in Tor that if > > they go bad, it will be worst then having your service become an onion > > service. But, this is where I guess people using Tor have to trust a bit the > > Tor Project that we did our best for the safety of our users which is the > > number *one* priority at all time for us, period. > > Hmm.. Despite our trust in others and belief in ourselves we are still > humans[*] and we still do mistakes. Saying something like "we catch bugs > fast enough and we don't produce many of them, one should trust us" is > not a solution for having less exploitable in future. I'm trying my best > at writing safe code. But I do know that there are plenty of bugs out > there. I hope to have none but I should be prepared to have many. > I agree with Hikki, isolating this *really dangerous* feature seems so > reasonable. Sure, there are also some unknown bugs somewhere else in > code, but keep in mind that they're spread over the code so they likely > [1] won't result in serious damage. In case of single onion services > there are so many places in the code that if something goes wrong here > the client is just plain naked explicitly. > Yes, it may seem like bikeshedding. Yes, maybe it's just some of us who > feel uncomfortable with this. But also worth noting that most of the > option checks (including SOS code) in little-t-tor are not written in > bitflip-safe manner [2][3]. So flipping of one (!) bit in the right > place of memory makes tor useless. Not just degradation of anonymity. > Just no anonymity at all. > And I'm sure that this is not the only problem that is out there. Let's > not put everything into one basket (like e.g. OpenSSL does). You are obviously right that _only_ the Tor code is not a "safe solution" but this is getting into a much broader discussion of "how really to make things safe with computers". Hardware, OSes, memory safe, etc... This will always influenced anything with do with the tor code. FYI, I won't start it here :P. Please keep in mind that our development team does take steps towards having safer code here. We use generated code for our binary parsing, we use static code analyzer, we test with ASAN, we have test network, we fuzz... I mean this is what I meant by "you have to trust us a bit" that is we do take steps to make it more then "we believe we do safe code". And there will ALWAYS be place for improvement over time. We have a project to increase the modularity of Tor which is to split functionalities into separate processes to decrease the attack surface if one is compromised for instance. Doing so takes _time_, huge amount of engineering effort and _testing_ but we'll get there someday. It can't happen overnight as Tor is not getting funding like Google can get and fire up a team of 50 engineers to pull it off. For now, we do add features for better security, for better performance but also to increase Tor adoptions. We do our very _best_ to make it safe but we never claimed that we do perfect safe code (which would be a sign that you shouldn't trust us anyway ;). And of course it is not a final solution to security. > > Personally I think the safest option here is to enable SOS code at > compilation time (there was a discussion long ago, so it's unlikely to > have this). Alec said that it would be complicated to manage separate > versions of this. I don't think so. If one wants to run a SOS they > should know what they're doing and thus install right packages. > > Another branch would be messy and hard to catch up with "upstream". In my opinion and experience, this is actually less safe. First of all, we have to build compile time conditionals in the code which makes *any* code base more messy, more prone to errors over time and thus less maintainable which is a very important thing to have as developers come and goes and the problem space of Tor is quite complex. Second, with an
Re: [tor-talk] Questions on the coming next-gen onion services
On 11 Feb (06:14:34), Lolint wrote: > Hi Hello! > > I have some questions about the coming switch to next-gen onion services: > > o What will happen to current onion services? Will they all be simply > discontinued or will there be a process by which they will be automatically > built again to form next-gen onions? The current services will still function for a while before we actually remove the support from tor. And that "while" will be few years at least. Both versions will live in parallel so you'll be able to have current service and next-gen service on the same tor instance. Currently, we do not plan to have an automatic transition to a next-gen address so if you want to create a next-gen address for your service, you'll have to simply configure a second service in the torrc indicating that you want the new version. We'll be documenting that process upon release. > > o What will happen to all the relays that are running versions of Tor that > don't support next-gen onion services? Good question. Onion services need basically three different type of relays, HSDir (directory), Intro point (IP) and Rendezvous Point (RP). The tor 0.3.0 release has the next-gen support for HSDir and IP. For the RP, the all current relays will work with next-gen. And for IP, next-gen services have a legacy option to use old IPs (<= 0.2.9). It has been put there for this transition period where we expect to have unfortunately a lot more tor out there that don't support next-gen. What is left is the HSDir that will have to be selected based on the protocol version advertised by the relay. So at first, there might be very few of those so there will be a period of time before we reached what we call "network maturity" which will allow us to switch from the current service protocol to the next-gen for all newly created services. This post on tor-dev@ kind of explain our intentions (but that might change overtime of course): https://lists.torproject.org/pipermail/tor-dev/2016-December/011725.html Cheers! David > > Thx --Jeff > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- D88plxd8YeLfCIVAR9gjiFlWB1WqpC53kWr350o1pzw= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Relay 0F11F8A09B27D29EC320F74CFEF13E7BD57A434A Ban ?
On 19 May (08:12:18), Seren wrote: > Hello, Hi, > > I'm running a Tor Relay (0F11F8A09B27D29EC320F74CFEF13E7BD57A434A) for the > last month, I had no issues but yesterday I’ve got disconnect/Ban for the Tor > network. Your relay has been detected to be harvesting .onion addresses. For that reason, we've rejected the relay from the network as this is not considered acceptable behavior from our ethics guideline perspective. https://blog.torproject.org/blog/ethical-tor-research-guidelines If you are _not_ doing such activity, then I would recommend to make sure your relay is running the intended version of tor or that it hasn't been tempered with. David > > The first message that I saw was "Fingerprint is marked rejected -- please > contact us?" and I read that It could be due outdated software so a ran > updates and regenerate relay keys. > > Unfortunately, now I get "Suspicious relay address range -- please contact > us?" > > I've searched for some information but I didn’t found too much, my suspicions > are: > > - I'm using port 443 (I did to try help skipping censorship, not sure it it > helps) > - I'm using OpenDNS free on my server (I didn't know that it could be a > problem) I think they are a trustworthyDNS, but I will change if this is the > problem. > > Please can you help me to know what I have to change/correct to bring back > the relay > > Thank you, > Seren > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- whkEaRrV3f3tiDOnVXl4Q/PRriN3ffflxJ6nEAIwP04= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] torified nodejs: server crashes
On 10 Feb (23:58:53), Konstantin Rybakov wrote: > Dear developers, > > I am trying to develop a simple networking application based on node.js > 'net' library. Server supposed to run in torified environment. > > My setup is linux Ubuntu 16.04. On 16.04, "torsocks" package is 2.1.0 which old so first thing you might want to do is try the latest that is torsocks 2.2.0. Building it from source is probably what you'll need to do (see the README.md in the tarball): https://people.torproject.org/~dgoulet/torsocks/torsocks-2.2.0.tar.xz Sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.2.0.tar.xz.asc > > intalled tor and torsocks. Torsocks allows inbound connection and outbound > on localhost. > > nodejs app is basically a minimal tcp server based on 'net' library. I run > it like this: torsocks nodejs app.js, while tor process is also runnning > > The server starts, but when client connects - it crashes with seg fault. > > When I run the same node.js server in regular shell without torsocks, but > when tor is running - it works fine > > So far I tried plain C and python servers - they both worked in torified > shell, but node.js failing. > > > Is there a way to make nodejs working under torsocks? What could be the > problem? Difficult to say. What I would do is open a ticket on trac.torproject.org under the "Core Tor/Torsocks" component if possible. If not, you can always email here some more details about the segfault. If you could do a couple of things and put those on the ticket or here. 1) Try this: $ TORSOCKS_LOG_LEVEL=5 TORSOCKS_LOG_FILE_PATH=/tmp/torsocks.log torsocks nodejs [...] 2) I have no idea what are the implication of using gdb with nodejs but you can try to use it and see where the segfaults happen: $ gdb nodejs set follow-fork-mode child set environment LD_PRELOAD /path/to/libtorsocks.so ["libtorsocks.so" is usually in "/usr/lib/torsocks/libtorsocks.so" or if you built it from source, will be in "/usr/local/lib/torsocks/libtorsocks.so"] run Then once you hit the segfault, use "bt full" to get a stack trace and put it on the ticket. 3) Finally, you could also use strace to see if it is within a syscall that torsocks hijacks that exploded: $ strace -f -o /tmp/strace-torsocks.log torsocks nodejs [...] Hope this help! Just a quick note, making the full nodejs work with torsocks could end up being quite complicated. You should also consider a way to use nodejs SOCKS proxy option (if any) instead and make your application use Tor socks port. Cheers! David -- 1xYrq8XhE25CKCQqvcX/cqKg04v1HthMMM3PwaRqqdU= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] V3 censorship ?
On 16 Apr (14:37:00), George Kadianakis wrote: > hi...@safe-mail.net writes: > > > I run both a V2 and V3 service on my Linux server. I'm using the same Tor > > process with both. The torrc file is fairly standard, except I'm forcing > > some custom entry nodes, and I compile Tor from source on Debian Stretch. > > > > The V2 service has worked flawlessly, more or less, for the last 5 years or > > so. It has about 98% uptime 365 days a year, according to my server stats. > > The server and Internet connection has always been fast and reliable. > > > > When I add a V3 address to my server, it works pretty much flawlessly as > > well, but *only* until I make the address public. Non-public V3 addresses > > have about 98-99% uptime per week/month. But after the address has been > > made public, and people have learned about it, its uptime is suddenly > > reduced to about 60%. It will be completely inaccessible for hours at a > > time. *While* on the same Tor process, the V2 address works without issues. > > > > By inaccessible I mean the same as having turned the service off. > > > > Later I create a new V3 address, which is non-public. Only I know about it. > > It has about 98% uptime and works fine. I leave it there for a while, and > > it still works fine. I then make it public on my website, and the next day > > it is inaccessible when trying it. Uptime drops from 98% to 60-70%, and > > from there on it becomes randomly inaccessible, 4-8 hours at a time. > > > > I tried for a third time, then fourth, and finally a fifth time, and the > > same pattern repeat itself, even with different and random timings. > > On the forth attempt I released the V3 address in public at the same moment > > it was created, and it never achieved anything above 60% uptime per week > > from the very beginning. > > > > I know the V3 system is new, and could have some undiscovered bugs, but my > > gut feeling tells me that someone, or something, is capable of censoring > > all my V3 addresses, while the old V2's are completely unaffected. > > > > Thanks for the report, Hikki! It's really valuable for us to receive > such reports from HSv3 operators given that the system is so new and > there are undiscovered bugs we should fix. > > Personally, I doubt this is a censorship attack by an adversary since > it's even harder to censor v3 onions than v2 onions. Of course, we can > never be sure. > > If I were to bet, I would bet that it's some sort of bug on the v3 > codebase, that perhaps could be triggering when it's getting used by > many people (hence why it appears when you make it > public). Unfortunately, there is no way to really know what's going on > except if we see some tor logs. And I would also be very interested in learning if your tor process was under a lot of load once your v3 got public? Do you usually have a lot of users going to these v3 once public? That is, are you expecting many users or it is mostly for yourself? We could have a reachability bug for a v3 under load like George pointed out. Logs would be great for us to learn more :). Thanks! David -- 6Tp7jGn7WrqP/fuiFYGnQDMFQrXAAl6FFg0lH5ttu1M= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] bug in tor 0.3.4.8?
On 17 Sep (15:06:11), Udo van den Heuvel wrote: > On 15/09/2018 18:14, Udo van den Heuvel wrote: > > I find a load of these bug mentions in the notices log. > > It happened again. > Any devs reading here? Hello Udo, I've opened https://trac.torproject.org/projects/tor/ticket/27750 with this problem. Quickly like that, I can't tell you why this is happening or any workaround you could do so keep an eye on the ticket. If this is an 0.3.4.x regression, we'll find it quickly. Thanks! David -- wIa6sCNt07pLMT/73mfGrHDTEF6JdA6MgE2IAeoKcYQ= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] [RELEASE] Torsocks 2.3.0
Hello everyone! Been a long time since a torsocks release! Many fixes went into this new version which all came from volunteers so huge thanks to you all for this work! ChangeLog below for this version. Please, let me know about any issues! I can't build on all systems so anyone testing this on Mac or/and BSD* would be great! We'll do a 2.3.1 release if anything comes up. 2018-11-19 torsocks 2.3.0 * Fix a bunch of stuff in the wrapper script, #24967 * gethostbyaddr_r: always assign result * log: Remove log line when logging is stopped * gethostbyaddr_r: Don't put garbage in data->hostname * gethostbyaddr_r: Populate h_addrtype field * log: Avoid crash or file corruption when closing logs * connect: Always pass .onion IP cookie to connection object * Merge remote-tracking branch 'yawning/bug23715' * Make torsocks always connect to the configured Tor port * test: Make getpeername test connect to moria1 * socks5: Always use ATYP 0x03 for CONNECT command * Merge remote-tracking branch 'upstream/master' * doc: Clarify the libc limitation in README * accept4: Initialize libc symbol early * Bug 23715: Support memfd_create(2). * test: Detect if tor is running in test_fd_passing * No tab in the README * Merge remote-tracking branch 'debian/bugfix/typo-subsytem' * Merge remote-tracking branch 'debian/bugfix/typo-catched' * Merge remote-tracking branch 'debian/bugfix/typo-conect' * doc: Add autogen.sh step to README * Add a -q/--quiet to torsocks * tests: Add a check for a running Tor * Make cpp conditional for definition of handle_mmap match use * utils: Add useful function for later use * man: Some words were missing * Remove clang warnings * Add missing quotes to variable in torsocks.in * Fix check_addr() to return either 0 or 1 * Ignore stderr for getcap command * syscall: Add seccomp, gettimeofday, clock_gettime, fork * Fix typo: conect → connect. * Fix typo: subsytem → subsystem. * Fix typo: catched → caught. Git: https://gitweb.torproject.org/torsocks.git Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.3.0.tar.xz (sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.3.0.tar.xz.asc) Cheers! David -- WiF7kGLc3KVl6aojs/i1iaeV3ElhHGWO4vmy2bqLS9E= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] more '8443+443' relays; MS3c relays;
On 13 Oct (19:27:00), nusenu wrote: > you might want to avoid using these Tor relays Bad relay team has asked the dirauths to reject these relays from the network. Cheers! David > > +-+-+--+-+-+--+---+ > | first_seen | IP | nickname | contact | tor_version | > fingerprint | as_name | > +-+-+--+-+-+--+---+ > | 2019-09-30 23:00:00 | 155.138.151.85 | Unnamed | NULL| 0.3.5.8 | > 3103D8D67D9BD8C3529200E1E443EE8505060EB8 | Choopa, LLC | > | 2019-09-30 23:00:00 | 144.202.62.99 | Unnamed | NULL| 0.3.5.8 | > 4C84764D7B320ADD4EB2E6758E3E5E77E7C0A63E | Choopa, LLC | > | 2019-09-30 23:00:00 | 45.77.224.247 | Unnamed | NULL| 0.3.5.8 | > 8672A04B841BE662584DC1E85B20AFECE70EA052 | Choopa, LLC | > | 2019-09-30 23:00:00 | 45.77.31.61 | Unnamed | NULL| 0.3.5.8 | > C3A9AB1D68D744DDC3FE6480720FD5CBEFF2F3B1 | Choopa, LLC | > | 2019-10-04 01:00:00 | 157.245.135.18 | Unnamed | NULL| 0.3.5.8 | > 385851C5F6CD03B872D235E885DA3D3D7B7157CF | DigitalOcean, LLC | > | 2019-10-04 01:00:00 | 165.22.108.147 | Unnamed | NULL| 0.3.5.8 | > CA59B5ACDA80F30B3A9C395157F50E1DF448A8F1 | DigitalOcean, LLC | > | 2019-10-04 02:00:00 | 206.189.61.74 | Unnamed | NULL| 0.3.5.8 | > 137A1DBA0A28754B83F72CD4BF9645AB4C59D0A5 | DigitalOcean, LLC | > | 2019-10-04 02:00:00 | 157.245.78.93 | Unnamed | NULL| 0.3.5.8 | > 4AAFD8106BC572BDAA062B88AA6F0C7FF8264947 | DigitalOcean, LLC | > | 2019-10-04 02:00:00 | 165.22.125.132 | Unnamed | NULL| 0.3.5.8 | > 8E5AC650145CCAD76B72FA24C848996235DBE0BC | DigitalOcean, LLC | > | 2019-10-04 02:00:00 | 165.227.75.125 | Unnamed | NULL| 0.3.5.8 | > CF1D5EA8B45C7887E363BFC3B3FF42249B838428 | DigitalOcean, LLC | > | 2019-10-04 02:00:00 | 167.99.176.172 | Unnamed | NULL| 0.3.5.8 | > E4F1EEA513BF83FCCC2E8C1CC3022FB41E369C04 | DigitalOcean, LLC | > | 2019-10-04 03:00:00 | 157.230.130.224 | Unnamed | NULL| 0.3.5.8 | > 3593C8D4CDDEECFF87497FE0E5A8FDD332FAAC9C | DigitalOcean, LLC | > | 2019-10-04 03:00:00 | 134.209.151.55 | Unnamed | NULL| 0.3.5.8 | > 939700C4582CF2A83F9E60E991E7B62EF5B2D143 | DigitalOcean, LLC | > | 2019-10-04 23:00:00 | 45.77.15.123| Unnamed | NULL| 0.3.5.8 | > 273CF9A4C93CA040CCF572C8C63D2A3DE281B6B2 | Choopa, LLC | > | 2019-10-04 23:00:00 | 155.138.143.136 | Unnamed | NULL| 0.3.5.8 | > D7E0E1A893C25760601AA47EB777E4076326C373 | Choopa, LLC | > +-+-+--+-+-+--+---+ > > https://nusenu.github.io/OrNetRadar/2019/10/04/a2 > https://nusenu.github.io/OrNetRadar/2019/10/04/a3 > https://nusenu.github.io/OrNetRadar/2019/09/30/a2 > > ++--+ > | nickname | fingerprint | > ++--+ > | MS3c490| 19ED956757A9D3F1427E1E0005C18531821376E2 | > | MS3c491| F49015D09397AE8BFFB9236B300F3EFC140ACF51 | > | MS3c494| 61965D16FA2FC02E6EC96AAB5F99EB34028ACDAD | > | MS3cTOR200 | C2AB7064BD225C673750D4BA405C46EA253FF787 | > | MS3cTOR49 | 38BAA789DE6C62DDB35AA5F71E1E5249F5D50824 | > | MS3cTOR493 | 5C5A32A576534482D0F9AE53D3AE9D964D939F6C | > | MS3cTOR524 | 79910C03FC49EA96498A5D296232790465F01293 | > | MS3cTOR525 | 7CFB357D0BD3E27D92D76D5F5EBDE0480438F208 | > | MS3cTOR526 | 4A38E4969213A6410E20A68FD477EA270A9872A5 | > | MS3cTOR527 | 69D92C811E428C30958798B2E78349D44D47E648 | > | MS3cTOR528 | 0E88FC7BB9F7D23D8676605E97469D410B687E52 | > | Ms3cTOR57 | 777A067D0C5D5DFEAFF206DF003BA19E7B8DFA0B | > | Ms3cTOR58 | 36B0248E61830048945C288A61FF8428BD6AA592 | > | MS3cTOR621 | 38D6F1A7802FEB6D1F6BF59C8B62BFDEA134C433 | > | Ms3cTOR621 | 4631F837CD293E577BD2A507D94496C25E58391D | > | Ms3cTor88 | F44C6C78F4C0183B449BF02254A9731589C88766 | > | MS3cTOR975 | 6205526BD99C666F341FF1604A62419D86DD6B17 | > ++--+ > > > -- > https://twitter.com/nusenu > https://mastodon.social/@nusenu > > > > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- dbrFXX9jKiutVmsk+lgFDK+5QdvuN562fbycQHdvZXI= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Dos defense .0.4.2.5
On 12 Dec (15:09:03), drl...@danwin1210.me wrote: Greetings, > How do I configure my hidden service to use the latest Dos defense in tor > 0.4.2.5. > > In my tor/torrc file underneath my hiddenservice info I added > > HiddenServiceEnableIntroDoSDefense 1 > HiddenServiceEnableIntroDoSRatePerSec 25 > HiddenServiceEnableIntroDoSBurstPerSec 200 > > and tried to reload tor which failed, I then tried remvoving the numbers > from the end and still failed. > > What am I doing wrong? Do I need to place it in a seperate location? These options need to be *under* the "HiddenServiceDir" since they are specific per HS. If it still fails, maybe providing the output of the error? Thanks! David -- 4YFecyn9YGuJQwVuyhI/lwP9tIQNYe5CLpTxrurYr7s= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Help setting up tor dos defense
On 19 Dec (12:38:35), brokenb...@danwin1210.me wrote: > Hello I run a forum hidden service and a former user is constantly > attacking it. > > I now have 0.4.2.5 installed and this is my torrc file the attacks still > persist do I need to add anything else or change these numbers I thought > this version of tor fixed these attacks was I mistaken? > > HiddenServiceDir /var/lib/tor/forum/ > HiddenServiceEnableIntroDoSDefense 1 > HiddenServiceEnableIntroDoSRatePerSec 25 > HiddenServiceEnableIntroDoSBurstPerSec 200 > HiddenServicePort 80 10.152.152.11:80 > HiddenServiceVersion 3 The above looks fine. I will expand on these defenses since it has been a recurrent theme lately: There is unfortunately a catch with these HS DoS defenses and it has to do because of a safety issue namely the "partition problem". Tor relays supporting the HS DoS defense (intro points) at this point in time are not in majority. Basically >= 0.4.2.1-alpha relays do support it which currently represents ~36% in bandwidth weight so roughly 1/3 of the network. If a service enables the defenses (like you did above), it will NOT specifically pick intro points supporting the defenses but will normally pick intro points as it did before and _if_ they happen to support the HS defenses (via protocol version "HSIntro=5"), then they are used. Yes, I agree, not ideal but there is a valid reason. This is in part to prevent partitionning onion services using the HS defenses to a specific set of relays (those who support it). Bottom line is: if the set of relays that can only be used by an onion service is reduced, attack surface gets bigger. As the relay in the network upgrades to latest stables, the network naturally move towards supporting these defenses in majority. This is another _extremely_ important reason why relay operators should stay up to date with their tor application so the network can be more agile in deploying defenses and improvements. Now onto "what this defense really does for your onion service?" question: Lets assume the attack here is a client DDoS meaning there are a gazillion clients trying to reach your service. Unfortuantely, this can bring down a service as it will be unable to cope with the amount of requests due to a number of factors that I will not cover with this email. More importantly, his has an immense toll on the network itself that is affecting everyone. What this defense does it to limit the number of client request that can *reach* the service by imposing a rate limitation at the intro point layer. In other words, this is primarly a defense to protect the _network_ which soaks in the extraneous client requests at the "edges" of the network (in this case more at the "edges of the onion service"). The main benefit for the service is that it will not be under heavy load and thus will still be usable/reachable for some definitions of "reachable". Because bad vs good client requests are basically indistinguishable at the intro point, legitimate clients get caught in this rate limitation resulting in them having a hard time to reach the service that is under attack. But, if your service happens to be under attack on a single .onion address but is configured with many more .onion, then these defenses makes it that through the other .onion addresses, it will be reachable without any problem which wasn't the case before. All in all, the network pressure is massively reduced due to this defense which overall is critical to the anonymity and stability properties of the network. Onion service reachability under DDoS is a hard problem and being researched: https://trac.torproject.org/projects/tor/ticket/31223 Hope this help! David -- j4GkCCMWq4EUJFogagt0wniDJJQgnGlBM/lXudVEJec= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Help setting up tor dos defense
On 07 Jan (15:38:46), s7r wrote: > David Goulet wrote: > > Tor relays supporting the HS DoS defense (intro points) at this point in > > time > > are not in majority. Basically >= 0.4.2.1-alpha relays do support it which > > currently represents ~36% in bandwidth weight so roughly 1/3 of the network. > > > > If a service enables the defenses (like you did above), it will NOT > > specifically pick intro points supporting the defenses but will normally > > pick > > intro points as it did before and _if_ they happen to support the HS > > defenses > > (via protocol version "HSIntro=5"), then they are used. Yes, I agree, not > > ideal but there is a valid reason. > > > > This is in part to prevent partitionning onion services using the HS > > defenses > > to a specific set of relays (those who support it). Bottom line is: if the > > set > > of relays that can only be used by an onion service is reduced, attack > > surface > > gets bigger. > > > > As the relay in the network upgrades to latest stables, the network > > naturally > > move towards supporting these defenses in majority. This is another > > _extremely_ important reason why relay operators should stay up to date with > > their tor application so the network can be more agile in deploying defenses > > and improvements. > > > > Sure - the best move to prevent onion services partitioning using this > HS defense. However, there is something unclear I'd like to understand. > From the manual: > > **HiddenServiceEnableIntroDoSDefense** **0**|**1**:: > Enable DoS defense at the intropoint level. When this is enabled, the > rate and burst parameter (see below) will be sent to the intro point > which will then use them to apply rate limiting for introduction request > to this service. > > The introduction point honors the consensus parameters except if this is > specifically set by the service operator using this option. The service > never looks at the consensus parameters in order to enable or disable > this defense. (Default: 0) > > So the service hosting the HS does not look at this consensus param. > Right now e do not have a consensus param for this at all, but what > will happen if the directory authorities will vote this consensus param > as HiddenServiceEnableIntroDoSDefense 1? In this case, the introduction > points will see that, and use the default values of 25 introductions per > second with a burst of 200 / sec. In this case, if a HS operator wants > to _disable_ this protection totally, he should set > HiddenServiceEnableIntroDoSRatePerSec 0 which according to the manual: > > "If this option is 0, it is considered infinite and thus if > **HiddenServiceEnableIntroDoSDefense** is set, it then effectively > disables the defenses."? Correct. A burst or rate that is 0 or crossing the upper limit, the intro point will disable the defenses because the parameters received are unusable, it does not fallback to the defaults. The good news is that the torrc config parser should prevent you from putting insane values but at the protocol level, it is still possible of course. > > Or should he just set HiddenServiceEnableIntroDoSDefense 0, which is > already 0 by default for _services_? (this is the confusing part). Just setting "HiddenServiceEnableIntroDoSDefense 0" is enough to disable the defense even if the consensus set it to 1. The intro point always use what the service specifies. If nothing present, then the consensus param is used. So for the case that the service sets "HiddenServiceEnableIntroDoSDefense 0", then that value is sent to the intro point indicating to disable the defense. Hope this answer your question David -- wlQW8e6zy9BjPFoNUszA+ip0Fa+lseCuCGd+6jzB1KI= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] New release candidate: Tor 0.4.5.4-rc
On 22 Jan (22:31:45), Roman Mamedov wrote: > On Fri, 22 Jan 2021 12:02:50 -0500 > Nick Mathewson wrote: > > > o Major bugfixes (authority, IPv6): > > - Do not consider multiple relays in the same IPv6 /64 network to be > > sybils. Fixes bug 40243; bugfix on 0.4.5.1-alpha. > > Each /64 should be treated as an equivalent to 1 address in the IPv4 world, so > it seems to me that the original code was correct. > > Any home user gets at least one /64 from their ISP [1]. It is not the minimum > routable block on the internet (as per bugreport[2]), the minimum is actually > a /48. But it is the minimum block that is usable on a LAN with SLAAC > auto-configuration, and as such is the minimum block any ISP will provide to a > home broadband subscriber. > > Some server hosts do put multiple distinct users within the same /64 -- but > they are wrong in doing that, there should be no pampering to that practice. > > I suggest to carefully reconsider if giving a free pass to run any number of > relays from a single /64, which are in most cases controlled entirely by a > single user, and then relying on path selection to limit the damage, is not > weakening the security model too much just to accommodate for a few bad > webhosts. Can you expand here on why you think an operator using a /64 is worst than an operator using an IPv4 /24 to run their relays? We have large Exit operators on the network that have racks of servers but only have a /48 available to them and thus they run a "fleet" of Exits on that very close by address range. Using the /128 we had before resulted in rejecting more than 400 relays from the network where all of them were actually legit known trusted operators and thus we expanded it to the /64 so a single operator is able to run more than one relay. It is important here to differentiate path selection versus sybil detections. Path selection will _not_ select an IPv6 in the same /32 (which is quite large) and /16 for IPv4. As for sybil, we are looking for more than 2 relays per address which is the limit that has been for a long time now. That is true on IPv4 and IPv6 as well, the checked masked are /32 and /128 respectively. David -- oFZnajOPJcaQecK8AioF3oEEaRTVRDiHEMRM2fdYOtc= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] [RELEASE] 0.3.5.17, 0.4.5.11, 0.4.6.8 and 0.4.7.2-alpha
Greetings! The Tor Network Team will from now on do its release announcement through our new fancy shiny Discourse forum: https://forum.torproject.net If you are interested in getting notified for each release announcement, you should follow this category (once you get an account): https://forum.torproject.net/c/news/tor-release-announcement/28 And for todays' announcement: https://forum.torproject.net/t/release-0-3-5-17-0-4-5-11-0-4-6-8-and-0-4-7-2-alpha/148 Cheers! David -- QH6XWXtrL9blSvXbw+DdZkn1Xx2UJnR2X56tf0A+EeA= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [tor-announce] [RELEASE] 0.3.5.17, 0.4.5.11, 0.4.6.8 and 0.4.7.2-alpha
On 26 Oct (18:58:53), mick wrote: > On Tue, 26 Oct 2021 11:48:54 -0400 > David Goulet allegedly wrote: > > > The Tor Network Team will from now on do its release announcement > > through our new fancy shiny Discourse forum: > > https://forum.torproject.net > > > > If you are interested in getting notified for each release > > announcement, you should follow this category (once you get an > > account): > > > > https://forum.torproject.net/c/news/tor-release-announcement/28 > > > > And for todays' announcement: > > > > https://forum.torproject.net/t/release-0-3-5-17-0-4-5-11-0-4-6-8-and-0-4-7-2-alpha/148 > > > > David > > I do hope that this new forum is a supplement to, and not a > substitution for, the current email based Tor lists. It will supplement. We are working on setting up a way for the forum announcement to be replicated onto mailing lists. David -- QH6XWXtrL9blSvXbw+DdZkn1Xx2UJnR2X56tf0A+EeA= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] [RELEASE] Tor 0.4.6.9 and 0.4.7.3-alpha
Greetings, We just released 0.4.6.9 and 0.4.7.3-alpha. You can find out about it here: https://forum.torproject.net/t/release-0-4-6-9-and-0-4-7-3-alpha/1265 Download at: https://dist.torproject.org Inline ChangeLog for both versions: Changes in version 0.4.7.3-alpha - 2021-12-15 This third alpha release of the 0.4.7.x series fixes several bugs including two major ones affecting Bridges and Relays (see below). If you are running an earlier 0.4.7.x version, you should upgrade to this version. o Major bugfixes (bridges): - Make Tor work reliably again when you have multiple bridges configured and one or more of them are unreachable. The problem came because we require that we have bridge descriptors for both of our first two bridges (else we refuse to try to connect), but in some cases we would wait three hours before trying to fetch these missing descriptors, and/or never recover when we do try to fetch them. Fixes bugs 40396 and 40495; bugfix on 0.3.0.5-rc and 0.3.2.1-alpha. o Major bugfixes (relay, overload): - Change the MetricsPort DNS "timeout" label to be "tor_timeout" in order to indicate that this was a DNS timeout from tor perspective and not the DNS server itself. - Deprecate overload_dns_timeout_period_secs and overload_dns_timeout_scale_percent consensus parameters as well. They were used to assess the overload state which is no more now. - Don't make Tor DNS timeout trigger an overload general state. These timeouts are different from DNS server timeout. They have to be seen as timeout related to UX and not because of a network problem. Fixes bug 40527; bugfix on 0.4.6.1-alpha. o Minor feature (reproducible build): - The repository can now build reproducible tarballs which adds the build command "make dist-reprod" for that purpose. Closes ticket 26299. o Minor features (compilation): - Give an error message if trying to build with a version of LibreSSL known not to work with Tor. (There's an incompatibility with LibreSSL versions 3.2.1 through 3.4.0 inclusive because of their incompatibility with OpenSSL 1.1.1's TLSv1.3 APIs.) Closes ticket 40511. o Minor features (fallbackdir): - Regenerate fallback directories generated on December 15, 2021. o Minor features (geoip data): - Update the geoip files to match the IPFire Location Database, as retrieved on 2021/12/15. o Minor features (portability): - Try to prevent a compiler warning about printf arguments that could sometimes occur on MSYS2 depending on the configuration. Closes ticket 40355. o Minor bugfix (pluggable transport): - Do not kill a managed proxy if one of its transport configurations emits a method error. Instead log a warning and continue processing method arguments. Fixes bug 7362; bugfix on 0.2.3.6-alpha. o Minor bugfixes (bridges): - When we don't yet have a descriptor for one of our bridges, disable the entry guard retry schedule on that bridge. The entry guard retry schedule and the bridge descriptor retry schedule can conflict, e.g. where we mark a bridge as "maybe up" yet we don't try to fetch its descriptor yet, leading Tor to wait (refusing to do anything) until it becomes time to fetch the descriptor. Fixes bug 40497; bugfix on 0.3.0.3-alpha. o Minor bugfixes (compilation): - Fix our configuration logic to detect whether we had OpenSSL 3: previously, our logic was reversed. This has no other effect than to change whether we suppress deprecated API warnings. Fixes bug 40429; bugfix on 0.3.5.13. o Minor bugfixes (controller, path bias): - When a circuit's path is specified, in full or in part, from the controller API, do not count that circuit towards our path-bias calculations. (Doing so was incorrect, since we cannot tell whether the controller is selecting relays randomly.) Resolves a "Bug" warning. Fixes bug 40515; bugfix on 0.2.4.10-alpha. o Minor bugfixes (logging): - When we no longer have enough directory information to use the network, we would log a notice-level message -- but we would not reliably log a message when we recovered and resumed using the network. Now make sure there is always a corresponding message about recovering. Fixes bug 40496; bugfix on 0.3.5.1-alpha. o Minor bugfixes (performance, DoS): - Fix one case of a not-especially viable denial-of-service attack found by OSS-Fuzz in our consensus-diff parsing code. This attack causes a lot small of memory allocations and then immediately frees them: this is only slow when running with all the sanitizers enabled. Fixes one c
[tor-talk] [RELEASE] Tor 0.3.5.18
Greetings! We just released 0.3.5.18. You can find out about it here: https://forum.torproject.net/t/release-0-3-5-18/1871 It is the last release of the 0.3.5.x series because it is reaching end-of-life in 7 days. Download at: https://dist.torproject.org Inline ChangeLog: Changes in version 0.3.5.18 - 2022-01-24 This is the very last version of the 0.3.5.x series as it is end of life on February 1st, 2022. This version fixes some minor bugs including a build warning about LibreSSL incompatibility with OpenSSL TLSv1.3. Godspeed 0.3.5, we won't miss you. o Minor feature (reproducible build): - The repository can now build reproducible tarballs which adds the build command "make dist-reprod" for that purpose. Closes ticket 26299. o Minor features (compilation): - Give an error message if trying to build with a version of LibreSSL known not to work with Tor. (There's an incompatibility with LibreSSL versions 3.2.1 through 3.4.0 inclusive because of their incompatibility with OpenSSL 1.1.1's TLSv1.3 APIs.) Closes ticket 40511. o Minor bugfix (logging): - Update a log notice dead URL to a working one. Fixes bug 40544; bugfix on 0.3.5.1-alpha. o Minor bugfix (relay): - Remove the HSDir and HSIntro onion service v2 protocol versions so relay stop advertising that they support them. Fixes bug 40509; bugfix on 0.3.5.17. o Minor bugfixes (compilation): - Fix our configuration logic to detect whether we had OpenSSL 3: previously, our logic was reversed. This has no other effect than to change whether we suppress deprecated API warnings. Fixes bug 40429; bugfix on 0.3.5.13. Cheers! David -- 3obTrBY9FLhQsK4/YufSTiyO7ERRvmLFjMaVvocpZfQ= signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
