- tor-dev - lists.torproject.org

Network Health Monitoring
by Iain Learmonth 21 May '19

21 May '19

Hi All, I'm working on #28322 to improve the monitoring of Tor Metrics services, but this also has the side effect of monitoring network health. For example, we'd like to know when Onionoo messes up and starts reporting zero relays, but we also get to learn for free in the same check how many relays we have and alert if that number does something weird. What would be the most useful checks to add here? * Range of expected total relays * Range of expected relays with Guard flag * Range of expected relays with Exit flag * Range of expected consensus weight in each position Each one of these is basically an if statement in the script so I'm happy to add these. I can do this by trial and error but if someone has already thought about it then please reply or comment on the ticket. Thanks, Iain.

3 2

Submit to FOCI '19: deadline in ten days
by Roger Dingledine 13 May '19

13 May '19

The submission deadline for this year's Free and Open Communications on the Internet (FOCI) workshop is coming up in ten days. The workshop will be co-located with Usenix Security in Santa Clara in August. https://www.usenix.org/conference/foci19 Here's the blurb: "The Free and Open Communications on the Internet (FOCI) workshop, now in its 9th year, is a vibrant, peer-reviewed event dedicated to bringing together researchers and practitioners from technology, law, and policy who are working on a wide variety of censorship-related topics. This includes direct censorship mechanisms---both technical and legal---as well as indirect methods of censorship through coordinated harassment campaigns and online astroturfing that may be used to drown out and/or chill free expression." We encouraged Susan and Michael, the chairs this year, to make it their own by adding the areas they find most fascinating, and they picked the harassment and astroturfing angle, which I agree needs much more attention from both the research and practitioner worlds. So, you should submit your workshop paper! And even if you don't submit, you should come to the workshop. There will be a bunch of great censorship circumvention and censorship measurement people there, including as usual some Tor people. --Roger

1 0

Re: [tor-dev] tor-dev Digest, Vol 100, Issue 8
by amar memisevic 08 May '19

08 May '19

1 0

My implementation of hash for controller password - torhash
by Damon (TheDcoder) 08 May '19

08 May '19

Hello everyone! I have written a very simple tool called torhash <https://github.com/TheDcoder/torhash> to generate hashed passwords/strings according to the instructions in control spec to authenticate with the controller interface (TC?). I did not actually study the S2K algorithm since I found it hard to understand RFC 2440, I studied source code and bit by bit I figured out what was happening behind the scenes! The reason I did this is that I am working on another program called ProxAllium <https://proxallium.dtw.tools/> which acts as a graphical user interface for Tor, I am currently in the process of rewriting <https://github.com/DcodingTheWeb/ProxAllium/tree/next-gen> it in C to make it cross-platform (along with a few other reasons...). I hit a roadblock while I was implementing support for interacting with the controller interface, I had to make a choice between calling Tor to generate the hashed password or to hash the password in the program itself. I felt like hashing the password in the program itself was the right choice, I had a few other weak reasons to not call Tor for hashing the password but my gut was the main motivator behind this choice. I created torhash (apologies about the bad name choice) as a proof-of-concept and to improve my general programming skills, I had no prior experience working with cryptography or hash functions on this level, so I went with the simplest library I could find for hashing the data. I could have gone with OpenSSL, as I believe that it is the de-facto cross-platform standard for cryptography and cryptographic hashing, I am currently looking into using it, but I am not yet sure if this is a good idea. I would be grateful if some of you can take out some time to have a look, I am very excited to hear your opinions and any advice that you may have to help me improve, the code itself is very simple and short (114 lines of code). Pardon any mistakes or bad code that I may have written, I have only begun programming relatively recently and my experience with low-level development (with C) is very recent. Thank you for reading and for the input in advance! Best Regards, Damon H. (TheDcoder)

2 1

Solving World's Tor Users Being Blocked by Websites (was: Tor exit bridges)
by grarpamp 08 May '19

08 May '19

On 5/7/19, nusenu <nusenu-lists(a)riseup.net> wrote: > > juanjo: >> Tor relays are public and easily blocked by IP. To connect to Tor >> network users where Tor is censored have to use bridges and even PTs. >> But, what happens on the exit? Many websites block Tor IPs so using >> it to access "clearweb" is not possible. Should we allow and start >> using "exit bridges"? In I2P we have not this problem since there is >> no central IP list of relays. > > there is no need to extend to one more hope to achieve this > > https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.html > > https://lists.torproject.org/pipermail/tor-relays/2019-May/017273.html It's possible to augment such outbound solution offerings even further by running an OpenVPN termination service so users can transport UDP between clearnet as well. VPNGate.net project has an idea there too. Even large regional IPv6 pools could be bought and shared by operators and rotated through. More tor relay operators should consider some of the above options, whether as a requested "bridge" service mechanism, or listed in the consensus "contact" field, or as more of a standalone VPNGate support, or "ExitGate" project sort of arrangement. Using only tor right now, a user needs to use a clearnet service that does not scrape consensus, or one not fronted by services doing similar to CloudFlare's spiteful default tor blocking policy, or find a lucky exit within whatever geolocation game the clearnet service uses, or get lucky through traditional vpn or proxy. But those are only fun statistical hacks, not real long term solutions to the underlying problem. It's unfortunate that such braindead blocking, stupid policy regimes, sites refusal to developing creative solutions [1] for so many world's users legitimate privacy, info risk, anonymity needs... often results in users accounts being locked out and escalated into forcing disclosure of users private info and ID to sites to unlock them, thus exposing users to ongoing long term fraud, cost, and stress when that info (in most cases truly unnecessary to collect) is eventually shared misused and stolen by both sites and criminals... or outright auto deletion of user's valued account, built up social networks, etc... all for doing nothing wrong, and harming no one or thing. Death by DriveByExit :( And really shameful to deny world's users the right to simply read a website, be it social, commercial, information, etc or even sadly their own tax-theft funded governmental public sites doing this blocking too. There are some related projects, best practice, as well... https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor https://trac.torproject.org/projects/tor/wiki/org/projects/DontBlockMe https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-access Positive outreach and direct engagement by Tor community is key here, and perhaps not enough of that is happening, at least not publicly. It's a big enough issue that it really needs a dedicated, active, allied, and even funded subproject... a MegaProject that needs to happen. [1] Such as forfeitable cryptocurrency and mailed-in cash deposits refundable in time, increasing account priviledges and features based on account age and activity, community moderation and behaviour support within the sites, opensource third party tracking-free local SecurImage style captcha throughout a sites features, privacy preserving non-SMS non-Google/Apple pure TOTP authenticator protocols, PGP recovery, letting users simply *read* websites without any hindrance, while utilizing these methods only for *write* operations, etc and so many more ways you can envision... Cc'd for awareness and inclusion. *Please remove tor-dev and tor-relays, and move this to tor-talk or tor-access for ongoing discussion and progress. Thanks.

1 0

Controller: text connection vs SNMP
by grarpamp 07 May '19

07 May '19

Speaking of MIBs and management, was SNMP ever seriously looked at back when desire for a control mechanism evolved? If I recall, agent libs and clients weren't wished as middleware, thus demurring to a text connection shell interface. Though commercial routers have both, the shell connection is usually richer and more capable, but harder to parse (Juniper being more programmatic), and requires downstream development to speak to each vendor's shell in automated fashion.

1 0

Tor exit bridges
by juanjo 07 May '19

07 May '19

Tor relays are public and easily blocked by IP. To connect to Tor network users where Tor is censored have to use bridges and even PTs. But, what happens on the exit? Many websites block Tor IPs so using it to access "clearweb" is not possible. Should we allow and start using "exit bridges"? In I2P we have not this problem since there is no central IP list of relays.

3 2

[RFC] control-spec: Specify add/remove/view client auth commands (client-side).
by George Kadianakis 07 May '19

07 May '19

Hello list, here is a control spec patch for adding v3 client auth commands to add/remove/view clients from the client-side (so Tor Browser -> Tor): https://github.com/torproject/torspec/pull/81/commits/3a26880e80617210b4729… I'm currently unhappy with the naming of those commands, and in general with how easy it is to confuse them with the (non-existent) service-side commands. I'm wondering how to name them better so that when we add the respective service-side commands (at some point we should) there is no confusion. Let me know what you think! Thanks! :)

6 9

Fuck You Van Gegel
by Mark Kepler 07 May '19

07 May '19

Fuck You Van Gegel, you dumb fuck. You think you can post stupid shit to our lists? I'm going to stop you from postiing you dumb motherfucker. I'm going to eat you alive. You're a dumb cocksucking faggot and I enjoyed fucking your mother in her face. I yelled FACE FUCK while I was doing it BITCH. You DONT KNOW SHIT AND YOU ANNOY AND HARRASS PEOPLE WITH YOUR BULLSHIT. YOU WILL STOP POSTING HERE YOU DUMB MOTHER FUCKER. WE WILL GET YOU. WE WILL FIND YOU. WE WILL KILL YOU. LOLOLOLOL.

2 1

(no subject)
by ttoto Q 04 May '19

04 May '19

confirmar 0ef436bfd7e6ffc09e94bdfa53554c4eeb67bd72

1 0