- tor-dev - lists.torproject.org

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

Proposing sbws changes
by teor 23 Apr '19

23 Apr '19

Hi all, We finished our first working version of sbws in March, and deployed it to a directory authority. We're now working on deploying it to a few more directory authorities: https://trac.torproject.org/projects/tor/ticket/29290 We're also working on archiving and analysing the bandwidth files produced by sbws and Torflow: https://trac.torproject.org/projects/tor/ticket/21378 During this work, we've discovered some missing sbws features: https://trac.torproject.org/projects/tor/ticket/30255 We need a better process for proposing and reviewing sbws changes. At the moment, I am spending a lot of time reviewing and designing sbws changes. And that's not sustainable. We need a process that works when I go on leave, or get busy with other tasks. I suggest that we use the tor proposals process: https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt We can submit small changes as diffs to the bandwidth file spec: https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt But large changes, controversial changes, and changes with multiple competing options should have their own proposal. Then, once we decide what to do, we can integrate those changes into the spec. T -- teor ----------------------------------------------------------------------

1 1

PrivCount Status
by teor 23 Apr '19

23 Apr '19

Hi, Nick asked me to send a status email about PrivCount, before I go on leave for a few weeks. Plan We want to add the following counters to a PrivCount Proof of Concept: * check counters (zero, relay count, time in seconds) * consumed bandwidth Nick also suggested adding connection counts. That seems like a good counter, but we want to make sure we do bandwidth in the first release, because it's a high-risk statistic. Status In March and April, I deferred PrivCount tasks to work on chutney for one of our other sponsors. I also delayed these tasks, because I was waiting for #29017 and #29018 to merge: * #29017 PaddingStatistics should be disabled when ExtraInfoStatistics is 0 * #29018 Make all statistics depend on ExtraInfoStatistics Tickets The top-level ticket is: PrivCount proof of concept with existing statistics https://trac.torproject.org/projects/tor/ticket/27908 I was mainly working on code for these tickets: PrivCount proof of concept: implement check counters https://trac.torproject.org/projects/tor/ticket/29004 PrivCount proof of concept: implement consumed bandwidth counters https://trac.torproject.org/projects/tor/ticket/29005 Make relays report bandwidth usage more often in test networks https://trac.torproject.org/projects/tor/ticket/29019 Code I have incomplete branches for #29004, #29005, and #29019 here: https://github.com/teor2345/tor/tree/ticket29004-wip https://github.com/teor2345/tor/tree/ticket29005 https://github.com/teor2345/tor/tree/ticket29019 I think all the necessary code is present in these branches. (But maybe it's not???) But it needs some cleanup: * rebase on to the current master, * put the commits on the right branches * make sure it does what these tickets say it should do I'm happy to do that after I come back from leave. I am also happy if Nick wants to clean up this code. See also my previous email about BridgeDB and PrivCount. Maybe we can save ourselves some effort by using PrivCount's obfuscation on BridgeDB's statistics. T -- teor ----------------------------------------------------------------------

1 0

Export BridgeDB usage statistics
by Philipp Winter 23 Apr '19

23 Apr '19

Hi Karsten, I'm working on <https://bugs.torproject.org/9316>, which will make BridgeDB export usage statistics. I would like these statistics to be public, privacy-preserving, and -- ideally -- added to Tor Metrics. I wanted to hear your thoughts on 1) what statistics we should collect, 2) how we can collect these statistics safely, and 3) what format these statistics should have. Broadly speaking, these statistics should answer the following questions: * How many requests does BridgeDB see per day? * What obfuscation protocols are the most popular? * What bridge distribution mechanisms are the most popular? * From what countries do we see the most bridge requests? * How many BridgeDB requests fail and succeed, respectively? * How many requests does BridgeDB see from Yahoo/Gmail/Riseup? * How many HTTPS requests are coming from proxies? * How many requests are suspicious, and likely issued by bots? Each request to BridgeDB carries with it some information, which allows us to answer the above questions. I suggest that we collect the following: * The distribution mechanism. Currently, this is HTTPS, email, or Moat. * The requested transport. Currently this is vanilla, fte, obfs3, obfs4, or scramblesuit. * The request's origin. For Moat and HTTPS, it's the two-letter country code, e.g., IT for Italy. For email, it's the user's email domain (Gmail, Yahoo, or Riseup). * Whether the request was successful or unsuccessful, i.e., resulted in BridgeDB handing out bridges or not. * Whether the request was issued by a user or a bot. David suggested heuristics that would allow us to estimate if a request came from a bot: <https://bugs.torproject.org/9316#comment:19> I like these suggestions but I'm not sure yet how to encode them -- it's more complex than a simple binary flag. The combination of these statistics results in ~16,800 buckets (3 mechanisms * 5 transports * ~280 ISO country codes * 2 success states * 2 bot states). We only need to export statistics with non-empty buckets. To protect users whose request is the only one in a given bucket (e.g., there may be only one user in Turkmenistan who successfully requested an FTE bridge over HTTPS on 2019-04-02), we should bin the statistics by rounding them up to the next multiple of, say, 10. We should further export statistics infrequently -- maybe once a day. Here's an example of a simple CSV format that takes into account the above: timestamp,mechanism,transport,country|domain,success,count,origin 1555977600,https,vanilla,it,successful,40,user 1555977600,https,obfs4,ca,unsuccessful,10,user 1555977600,email,vanilla,yahoo.com,successful,50,user ... What are your thoughts? Thanks, Philipp

2 1

Next Network Team Meeting Time
by teor 18 Apr '19

18 Apr '19

Hi, The next network team meeting is at 2300 UTC on Tuesday 23 April. (Our "patch party" and "first meeting of the month" time.) Here is our schedule for the next few months: April schedule: * Tuesday 23 April at 2300 UTC (at the "patch party" time) * Monday 29 April at 1700 UTC May schedule: * Monday 6 May at 1700 UTC (first May meeting, but at the normal time) * Monday 13 May at 1700 UTC * Monday 20 May at 1700 UTC * Monday 27 May at 1700 UTC June schedule: * Tuesday 4 June at 2300 UTC (first meeting of the month) * Monday 10 June at 1700 UTC T -- teor ----------------------------------------------------------------------

3 4

Support for clients using shutdown(SHUT_WR)
by Rob Jansen 16 Apr '19

16 Apr '19

Hello! I'm in the process of re-writing Shadow's traffic generation tool called tgen [0], which now depends on shutdown() for two communicating tgen nodes to inform each other that they have no more to send (i.e. to perform graceful connection shutdowns). The shutdown() functionality is useful now that tgen uses Markov models to generate more realistic Tor traffic [1]. Currently, it appears that when the tor client receives a FIN on the AP connection (because the tgen client calls shutdown(SHUT_WR)), the tor client sends a RELAY_END cell to the exit relay to instruct it to close() the exit TCP connection to the server. The behavior I expected was something more like what is described in tor-spec in Section 6.3 (search for "RELAY_FIN") [2], where the tor client sends a RELAY_FIN cell to the exit to instruct the exit to perform a shutdown(SHUT_WR) on the exit TCP connection to the server. Is there any plan to support shutdown(SHUT_WR) using RELAY_FIN cells now that Tor is itself using shutdown()? (I didn't see any tickets about it after a brief search.) Thanks! Peace, love, and positivity, Rob [0] https://github.com/shadow/tgen [1] https://tmodel-ccs2018.github.io/ [2] https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt

2 1

ICLab testing of default bridges
by David Fifield 11 Apr '19

11 Apr '19

At the anti-censorship meeting today you mentioned talking to ICLab about testing the default bridges. I believe that ICLab is already testing at least a portion of the default bridges; they may have data that you just have to ask for. OONI and ICLab test the default bridges as a result of my, Lynn's, and Qi's asking them to while we were studying default bridge blocking. The data exist but we never carefully analyzed them. You can see what little analysis we did at https://arxiv.org/abs/1709.08718 Figure 1 and Section 5.9. The data we used is in data/iclab/tor_jsons.tar.bz2 in https://repo.eecs.berkeley.edu/git-anon/users/fifield/proxy-probe-paper.git. It's a lot of JSON files that have TCP connect, TLS certificate fetch, HTTP fetch, and TCP traceroute for each destination. We sent them the list of bridges in September 2016 and they started measuring shortly after that. The most recent update to the bridge list we sent them was in August 2017 for https://bugs.torproject.org/23166.

1 0