- tor-dev - lists.torproject.org

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 07 May '19

07 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 03 May '19

03 May '19

confirmar 0ef436bfd7e6ffc09e94bdfa53554c4eeb67bd72

1 0

[GSoD] Project 4: Help us write architecture documentation for Tor
by Pranam Lashkari 02 May '19

02 May '19

Hello, I want to participate in Google Season of Docs as a technical writer. I have closely looked at the ideas available on the ideas page and found project 4 interesting. I have also skimmed through the existing documentation for the same. What are the further procedures? (E.g: In GSoC most of the organizations make students take competency test or make them contribute by solving small bugs or patches) Do we have something similar in Tor for the GSoD? *About me:* I am a final year computer engineering student. I have been involved in open source since last two years. I have been a GSoC 2018 student with Boost C++ Libraries and Google Code-In mentor with KDE and JBoss. Apart from that, I would have been Admin of Boost C++ Library in GSoD but unfortunately, Boost isn't a part of GSoD this year due to limited slots for organizations in GSoD's pilot year. I initiated a technical newsletter at my college where I generated content for 1 year along with leading the committee for the same. This initiative involved writing tutorials for the new aspirants, reviewing trending technologies and documenting college projects. Thank you, Pranam Lashkari

1 0

Denial of service defences for onion services
by George Kadianakis 30 Apr '19

30 Apr '19

Hello list, This is a thread summarizing and brainstorming various defences about denial of service defences for onion services after an in-depth discussion with David Goulet. We've been thinking about denial of service defences for onion services lately. This has been a recurrent topic that has been creeping up every once in a while: Last time we had to tackle this issue it was back in early 2018 when we had to design a DoS mitigation subsystem because the network was crumbling down (https://trac.torproject.org/projects/tor/ticket/24902) Unfortunately, while the DoS mitigation subsystem improved the health of the network and stopped the DoS attacks back then, it did not address the total space of possible attacks, and onion services and the network is still open to various attacks. The main DoS attack right now is the naive attack of flooding the service with too many introduction requests, and this is the attack that this post is gonna be dealing with. We don't like DoS attacks because they cause two issues to Tor: a) They damage the health of the Tor network impacting every user b) They kill availability of legitimate onion services. In this thread we will handle these two issues independently, as there is no single solution that improves both areas at once. We have some pretty good ideas on (a), but we would appreciate ideas on (b), so feel free to give us your input. == a) Minimizing the damage to the network caused by DoS attacks: Most of the damage caused during DoS attacks is from the circuits created by the attacker to introduce/rendezvous to the victim onion service, and also by the circuits created by the victim onion service as it tries to rendezvous with all those clients. An attacker can literally create tens of thousands of introduction circuits in less than a minute, which get amplified by the service launching that many rendezvous circuits. Not good. Here are a few ways to reduce the damage to the network: == 1) Rate limiting introduction circuits There should be a way to rate-limit introductions so that services do not get overwhelmed. There are various places where we can rate-limit: we could rate-limit on the guard-layer, or on the intro-point layer or on the service-layer. We have already attempted at rate-limiting on the guard-layer with #24902, but it's hard to go deeper there because the guard does not know if the circuit is a DoS attacker, or a busy onion service, or 150 Tor users in an airport. We also think that rate-limiting on the service-layer won't do much good since that's too far down the circuit, and we are trying to reduce the operations it has to do so that it doesn't get overwhelmed (see #15463 for various queue-management approaches for rate-limiting on the service side). So we've been thinking of rate-limiting on the introduction point layer, since it's a nice soaking point that does not do much right now. See #15516 (comment 28) for a concrete proposal by arma which results in far less damage to the network (since evil traffic does not get carried through to the service-side introduction circuit, and no extra rendezvous circuits get launched), and also a swifter way for legit clients to know that an onion-service circuit won't work. == 2) Stop needless circuit rotation on service-side Right now, services will rotate their introduction circuits after a certain number of introductions (#26294). This means that during an attack, the service not only needs to handle thousands of fake introduction circuits, but also continuously tear down and recreate introduction circuits and publish new descriptors. See comment 8 on that ticket for a short-term proposal on how to improve the situation here, by not continuously rotating introduction points. == 3) Optimize CPU performance on the service-side Right now, onion services during an attack are actually CPU bound. See #30221 for various improvements we can do to improve the performance of services. However, improving CPU performance might have the opposite effect, since processing cells quicker means that the service will make even more rendezvous circuits. == 4) Make sure attackers don't take shortcuts around the protocol We should make sure that attackers don't take shortcuts around the Tor protocol to launch their attacks. Examples here involve requiring a proof-of-rendezvous from clients (#25066), and not allowing single-hop proxies to do introductions (#22689). The above suggestions (maybe in priority order) are ways we can improve the damage dealt to the network by DoS attackers. But that still does not make DoS attacks less effective. So here follows the section about improving service availability: == b) Improve service availability during DoS attacks Unfortunately, it's really hard to accurately stop DoS attacks in the Tor protocol. There is just no good way to distinguish between innocent clients trying to access content, and a bad actor trying to disable an onion service. Here is the main way we've thought of addressing this issue: == 1) Binding the application-layer with the Tor introduction-layer We think that the Tor protocol layer might not be the right place for handling DoS attacks. There are literally million-dollar companies trying hard to tackle this issue on the application-layer, where it's easier since you can do machine learning, give out captchas, zone out users, etc. And that's why we think that the solution to this issue lies on the application-layer and not on the Tor protocol layer. In particular, a plausible solution here might involve for the client to embed application-layer information (e.g. a username/password) in its INTRODUCE1 cell, which then gets passed to the service. The service, can then check whether the given username/password should be allowed to connect (see "rendezvous approver" concept at #16059), and allow or reject the connection as it wishes. This way onion service operators can have complicated application-layer software that analyzes the activity of users and decide whether users should be allowed in or not (based on the number of introductions, or their application-layer (web) activity). +===========================================+ | Tor network | +===========================================+ ^ ^ | +-----+ | +-------->| Tor |-------------------+ INTRO2 | HS | rendezvous circuit with +-----+ only if approved user/pass ^ | | v +----------+ +-------+ |Rendezvous|<------->|sqlite?| |approver | +-------+ +----------+ We think that this is a solution that could allow onion services to continue existing under high-load scenarios, since no rendezvous circuits would be established during DoS scenarios (and we know that rendezvous circuits is what causes the most CPU/network/availability damage). However, this is a very complicated solution from an engineering perspective given that it requires changes on the client-side (to enhance INTRO1 cells with application-layer data), and also involves various enhancements on the service-side (various control port commands to interact with the (nonexistent) "rendezvous approver" software, which in turn needs to interact with other application-layer software (e.g. sql databases to manage membership). There is also serious UX concerns with how this would look like on the client-side? Also, how does this interact with client auth? And how does this interact with intro-point-level rate limiting proposed above (onions should be given the option to disable intro-layer rate limiting)? How is this related to #17254? All in all, we feel like we have pretty good options for reducing the damage that DoS attacks cause on our network, but we are still lacking easy and practical solutions for ensuring availability of onion services that are under DoS. For the next months, we plan to focus on reducing the damage on the network, since the damage on the network has a cummulative effect as circuits fail and get endlessly retried, where nothing ends up working right. At the same time, we will be thinking of good solutions for keeping a high availability on services that receive DoS attacks. We would love your feedback and suggestions. Thanks!

1 0