- tor-dev - lists.torproject.org

Re: [tor-dev] [prop-meeting] [prop#267] "Tor Consensus Transparency"
by Tom Ritter 21 Feb '18

21 Feb '18

On 17 February 2018 at 00:31, isis agora lovecruft <isis(a)patternsinthevoid.net> wrote: > 1. Tuesdays @ 18:00 UTC (10:00 PST/13:00 EST/20:00 CET/05:00+1 AEDT) This time works for me. -tom

3 2

Nominate/vote for future proposal discussion meetings!
by isis agora lovecruft 21 Feb '18

21 Feb '18

Hello all, Is there an existing Tor proposal you'd like to discuss? Please use the following pad to nominate and vote for proposals for discussion. https://pad.riseup.net/p/Pxo2fQiiaSWo We'll be reviving our proposal discussion meetings soon, likely at the beginning of January once people have returned from their winter holidays. After the nominations/votes are taken, I'll start arranging meeting times. If you nominate and/or vote for a proposal, I may reach out to you at some point for … [View More]

6 18

Enhancement for Tor 0.3.4.x
by David Goulet 19 Feb '18

19 Feb '18

Hello everone! As an effort to better organize our 0.3.4.x release for which the merge window opens in 3 days (Feb 15th, 2018), we need to identify the enhancement(s) that we want so we can better prioritize the development during the merge window timeframe (3 months). Each feature should have its ticket marked for 0.3.4 milestone and with an Owner set so we know who is "leading" that effort. It doesn't have to be the person who code the whole thing but should be a good point of contact to … [View More]

5 6

Cross compiling Tor for Windows
by Alexander Færøy 19 Feb '18

19 Feb '18

Hello. I have recently been trying to wrap my head around some of the Windows/Unix I/O code of Tor to do an API experiment with the PT subsystem. While working on this I remembered that Nick did a cool trick during the development of the consensus diff feature where he managed to reproduce a Windows only test case failure with Wine on Linux using a cross compiled version of Tor that he build on Linux as well. I wanted to try out if I was able to make use of this "trick" as well and decided … [View More]

1 0

monitoring significant drops of flags in dirauth votes
by nusenu 17 Feb '18

17 Feb '18

Hi Damian and Tom, Roger discovered that dannenberg did not include any exit flags in certain votes anymore [1]. It would be great if we would detect and notify about such events in the future. I see two places where this could be added: DocTor: a new check that alerts on events where a certain dir auth does either no longer include certain flags (guard, hsdir, exit, ..) at all or better: if the amount of relays with a certain flag significantly dropped by xx % from one vote to the next. … [View More]

5 12

Atlas is not that friendly to Web Archive
by Leonid Evdokimov 13 Feb '18

13 Feb '18

Hello! I've recently found out that new Atlas re-design is not that friendly to web archive. http://archive.li/ can't properly detect "page loaded" event that leads to capturing "loading" page[%]. Moreover, https://web.archive.org/ can't capture #-based links at all, as far as I see. [%] https://archive.li/https://atlas.torproject.org/%23details/5C3B8FB35A13C508… Ability to archive atlas pages is kinda nice to be able to "cite" some relay status in some specific date as Atlas has no it's … [View More]

2 1

Proposal: Authenticating sendme cells to mitigate bandwidth attacks
by Roger Dingledine 13 Feb '18

13 Feb '18

Filename: xxx-authenticated-sendmes.txt Title: Authenticating sendme cells to mitigate bandwidth attacks Author: Rob Jansen, Roger Dingledine Created: 2016-12-01 Status: open 1. Overview and Motivation In Rob's "Sniper attack", a malicious Tor client builds a circuit, fetches a large file from some website, and then refuses to read any of the cells from the entry guard, yet sends "sendme" (flow control acknowledgement) cells down the circuit to encourage the exit relay to keep … [View More]sending more cells. Eventually enough cells queue at the entry guard that it runs out of memory and exits [0, 1]. We resolved the "runs out of memory and exits" part of the attack with our Out-Of-Memory (OOM) manager introduced in Tor 0.2.4.18-rc. But the earlier part remains unresolved: a malicious client can launch an asymmetric bandwidth attack by creating circuits and streams and sending a small number of sendme cells on each to cause the target relay to receive a large number of data cells. This attack could be used for general mischief in the network (e.g., consume Tor network bandwidth resources or prevent access to relays), and it could probably also be leveraged to harm anonymity a la the "congestion attack" designs [2, 3]. This proposal describes a way to verify that the client has seen all of the cells that its sendme cell is acknowledging, based on the authenticated sendmes design from [1]. 2. Sniper Attack Variations There are some variations on the attack involving the number and length of the circuits and the number of Tor clients used. We explain them here to help understand which of them this proposal attempts to defend against. We compare the efficiency of these attacks in terms of the number of cells transferred by the adversary and by the network, where receiving and sending a cell counts as two transfers of that cell. 2.1 Single Circuit, without Sendmes The simplest attack is where the adversary starts a single Tor client, creates one circuit and two streams to some website, and stops reading from the TCP connection to the entry guard. The adversary gets 1000 "attack" cells "for free" (until the stream and circuit windows close). The attack data cells are both received and sent by the exit and the middle, while being received and queued by the guard. Adversary: 6 transfers to create the circuit 2 to begin the two exit connections 2 to send the two GET requests --- 10 total Network: 18 transfers to create the circuit 22 to begin the two exit connections (assumes two for the exit TCP connect) 12 to send the two GET requests to the website 5000 for requested data (until the stream and circuit windows close) --- 5052 total 2.2 Single Circuit, with Sendmes A slightly more complex version of the attack in 2.1 is where the adversary continues to send sendme cells to the guard (toward the exit), and then gets another 100 attack data cells sent across the network for every three additional exitward sendme cells that it sends (two stream-level sendmes and one circuit-level sendme). The adversary also gets another three clientward sendme cells sent by the exit for every 100 exitward sendme cells it sends. If the adversary sends N sendmes, then we have: Adversary: 10 for circuit and stream setup N for circuit and stream sendmes --- 10+N Network: 5052 for circuit and stream setup and initial depletion of circuit windows N*100/3*5 for transferring additional data cells from the website N*3/100*4 for transferring sendmes from exit to client --- 5052 + N*166.79 It is important to note that once the adversary stops reading from the guard, it will no longer get feedback on the speed at which the data cells are able to be transferred through the circuit from the exit to the guard. It needs to approximate when it should send sendmes to the exit; if too many sendmes are sent such that the circuit window would open farther than 1000 cells (500 for streams), then the circuit may be closed by the exit. In practice, the adversary could take measurements during the circuit setup process and use them to estimate a conservative sendme sending rate. 2.3 Multiple Circuits The adversary could parallelize the above attacks using multiple circuits. Because the adversary needs to stop reading from the TCP connection to the guard, they would need to do a pre-attack setup phase during which they construct the attack circuits. Then, they would stop reading from the guard and send all of the GET requests across all of the circuits they created. The number of cells from 2.1 and 2.2 would then be multiplied by the number of circuits C that the adversary is able to build and sustain during the attack. 2.4 Multiple Guards The adversary could use the "UseEntryGuards 0" torrc option, or build custom circuits with stem to parallelize the attack across multiple guard nodes. This would slightly increase the bandwidth usage of the adversary, since it would be creating additional TCP connections to guard nodes. 2.5 Multiple Clients The adversary could run multiple attack clients, each of which would choose its own guard. This would slightly increase the bandwidth usage of the adversary, since it would be creating additional TCP connections to guard nodes and would also be downloading directory info, creating testing circuits, etc. 2.6 Short Two-hop Circuits If the adversary uses two-hop circuits, there is less overhead involved with the circuit setup process. Adversary: 4 transfers to create the circuit 2 to begin the two exit connections 2 to send the two GET requests --- 8 Network: 8 transfers to create the circuit 14 to begin the two exit connections (assumes two for the exit TCP connect) 8 to send the two GET requests to the website 5000 for requested data (until the stream and circuit windows close) --- 5030 2.7 Long >3-hop Circuits The adversary could use a circuit longer than three hops to cause more bandwidth usage across the network. Let's use an 8 hop circuit as an example. Adversary: 16 transfers to create the circuit 2 to begin the two exit connections 2 to send the two GET requests --- 20 Network: 128 transfers to create the circuit 62 to begin the two exit connections (assumes two for the exit TCP connect) 32 to send the two GET requests to the website 15000 for requested data (until the stream and circuit windows close) --- 15222 The adversary could also target a specific relay, and use it multiple times as part of the long circuit, e.g., as hop 1, 4, and 7. Target: 54 transfers to create the circuit 22 to begin the two exit connections (assumes two for the exit TCP connect) 12 to send the two GET requests to the website 5000 for requested data (until the stream and circuit windows close) --- 5088 3. Design This proposal aims to defend against the versions of the attack that utilize sendme cells without reading. It does not attempt to handle the case of multiple circuits per guard, or try to restrict the number of guards used by a client, or prevent a sybil attack across multiple client instances. The proposal involves three components: first, the client needs to add a token to the sendme payload, to prove that it knows the contents of the cells that it has received. Second, the exit relay needs to verify this token. Third, to resolve the case where the client already knows the contents of the file so it only pretends to read the cells, the exit relay needs to be able to add unexpected randomness to the circuit. (Note: this proposal talks about clients and exit relays, but since sendmes go in both directions, both sides of the circuit should do these changes.) 3.1. Changing the sendme payload to prove receipt of cells In short: clients put the latest received relay cell digest in the payload of their circuit-level sendme cells. Each relay cell header includes a 4-byte digest which represents the rolling hash of all bytes received on that circuit. So knowledge of that digest is an indication that you've seen the bytes that go into it. We pick circuit-level sendme cells, as opposed to stream-level sendme cells, because we think modifying just circuit-level sendmes is sufficient to accomplish the properties we need, and modifying just stream-level sendmes is not sufficient: a client could send a bunch of begin cells and fake their circuit-level sendmes, but never send any stream-level sendmes, attracting 500*n queued cells to the entry guard for the n streams that it opens. Which digest should the client put in the sendme payload? Right now circuit-level sendmes are sent whenever one window worth of relay cells (100) has arrived. So the client should use the digest from the cell that triggers the sendme. How shall we version the sendme payload so we can change the format of it later? Right now sendme payloads are empty. Here's a simple design: we use five bytes in the payload, where the first byte indicates the sendme payload version (0 in the original design, and 1 once we've implemented this proposal), and the rest of the payload is formatted based on the payload version number: in this case, it's simply the four bytes of digest. Is there a better way to version the payload, e.g. a way that is already standard in other parts of the design, so we aren't adding a new paint color to keep track of on the bike shed? 3.2. Verifying the sendme payload In the current Tor, the exit relay keeps no memory of the cells it has sent down the circuit, so it won't be in a position to verify the digest that it gets back. But fortunately, the exit relay can count also, so it knows which cell is going to trigger the sendme response. Each circuit can have at most 10 sendmes worth of data outstanding. So the exit relay will keep a per-circuit fifo queue of the digests from the appropriate cells, and when a new sendme arrives, it pulls off the next digest in line, and verifies that it matches. If a sendme payload has a payload version of 1 yet its digest doesn't match the expected digest, or if the sendme payload has an unexpected payload version (see below about deployment phases), the exit relay must tear down the circuit. (If we later find that we need to introduce a newer payload version in an incompatible way, we would do that by bumping the circuit protocol version.) 3.3. Making sure there are enough unpredictable bytes in the circuit So far, the design as described fails to a very simple attacker: the client fetches a file whose contents it already knows, and it uses that knowledge to calculate the correct digests and fake its sendmes just like in the original attack. The fix is that the exit relay needs to be able to add some randomness into its cells. It can add this randomness, in a way that's completely orthogonal to the rest of this design, simply by choosing one relay cell every so often and not using the entire relay cell payload for actual data (i.e. using a Length field of less than 498), and putting some random bytes in the remainder of the payload. How many random bytes should the exit relay use, and how often should it use them? There is a tradeoff between security when under attack, and efficiency when not under attack. We think 1 byte of randomness every 1000 cells is a good starting plan, and we can always improve it later without needing to change any of the rest of this design. (Note that the spec currently says "The remainder of the payload is padded with NUL bytes." We think "is" doesn't mean MUST, so we should just be sure to update that part of the spec to reflect our new plans here.) 4. Deployment Plan In phase one, both sides begin remembering their expected digests, and they learn how to parse sendme payloads. When they receive a sendme with payload version 1, they verify its digest and tear down the circuit if it's wrong. But they continue to send and accept payload version 0 sendmes. In phase two, we flip a switch in the consensus, and everybody starts sending payload version 1 sendmes. Payload version 0 sendmes are still accepted. In phase three, we flip a different switch in the consensus, and everybody starts refusing payload version 0 sendmes. (It has to be two separate switches, not one unified one, because otherwise we'd have a race where relays learn about the update before clients know to start the new behavior.) We'll want to do a bunch of testing in chutney before flipping the switches in the real network: I've long suspected we still have bugs in our sendme timing, and this proposal might expose some of them. Alas, this deployment plan leaves a pretty large window until relays are protected from attack. It's not all bad news though, since we could flip the switches earlier than intended if we encounter a network-wide attack. 5. Security Discussion Does our design enable any new adversarial capabilities? An adversarial middle relay could attempt to trick the exit into killing an otherwise valid circuit. An adversarial relay can already kill a circuit, but here it could make it appear that the circuit was killed for a legitimate reason (invalid or missing sendme), and make someone else (the exit) do the killing. There are two ways it might do this: by trying to make a valid sendme appear invalid; and by blocking the delivery of a valid sendme. Both of these depend on the ability for the adversary to guess which exitward cell is a sendme cell, which it could do by counting clientward cells. * Making a valid sendme appear invalid A malicious middle could stomp bits in the exitward sendme so that the exit sendme validation fails. However, bit stomping would be detected at the protocol layer orthogonal to this design, and unrecognized exitward cells would currently cause the circuit to be torn down. Therefore, this attack has the same end result as blocking the delivery of a valid sendme. (Note that, currently, clientward unrecognized cells are dropped but the circuit is not torn down.) * Blocking delivery of a valid sendme A malicious middle could simply drop a exitward sendme, so that the exit is unable to verify the digest in the sendme payload. The following exitward sendme cell would then be misaligned with the sendme that the exit is expecting to verify. The exit would kill the circuit because the client failed to prove it has read all of the clientward cells. The benefits of such an attack over just directly killing the circuit seem low, and we feel that the added benefits of the defense outweigh the risks. 6. Open problems With the proposed defenses in place, an adversary will be unable to successfully use the "continue sending sendmes" part of these attacks. But this proposal won't resolve the "build up many circuits over time, and then use them to attack all at once" issue, nor will it stop sybil attacks like if an attacker makes many parallel connections to a single target relay, or reaches out to many guards in parallel. We spent a while trying to figure out if we can enforce some upper bound on how many circuits a given connection is allowed to have open at once, to limit every connection's potential for launching a bandwidth attack. But there are plausible situations where well-behaving clients accumulate many circuits over time: Ricochet clients with many friends, popular onion services, or even Tor Browser users with a bunch of tabs open. Even though a per-conn circuit limit would produce many false positives, it might still be useful to have it deployed and available as a consensus parameter, as another tool for combatting a wide-scale attack on the network: a parameter to limit the total number of open circuits per conn (viewing each open circuit as a threat) would complement the current work in #24902 to rate limit circuit creates per client address. But we think the threat of parallel attacks might be best handled by teaching relays to react to actual attacks, like we've done in #24902: we should teach Tor relays to recognize when somebody is *doing* this attack on them, and to squeeze down or outright block the client IP addresses that have tried it recently. An alternative direction would be to await research ideas on how guards might coordinate to defend against attacks while still preserving user privacy. In summary, we think authenticating the sendme cells is a useful building block for these future solutions, and it can be (and should be) done orthogonally to whatever sybil defenses we pick later. 7. References [0] https://blog.torproject.org/blog/new-tor-denial-service-attacks-and-defenses [1] https://www.freehaven.net/anonbib/#sniper14 [2] https://www.freehaven.net/anonbib/#torta05 [3] https://www.freehaven.net/anonbib/#congestion-longpaths [View Less]

3 2

Fwd: contribute to gsoc 2018 ideas
by Ankur Goyal 10 Feb '18

10 Feb '18

Hello, I am going to participate in gsoc 2018 and i want to contribute in your idea,can anyone provide me some more pointers about how to move forward. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0

Re: [tor-dev] Starting with contributing to Anonymous Local Count Statistics.
by Aruna Maurya 09 Feb '18

09 Feb '18

Hey! What is the current status of the project, how much work has been done and where can I pick up from? On Fri, Feb 2, 2018 at 3:04 PM, Aruna Maurya <aruna.maurya12(a)gmail.com> wrote: > > ---------- Forwarded message ---------- > From: George Kadianakis <desnacked(a)riseup.net> > Date: Wed, Jan 31, 2018 at 6:32 PM > Subject: Re: [tor-dev] Starting with contributing to Anonymous Local Count > Statistics. > To: Aruna Maurya <aruna.maurya12(a)gmail.com>,… [View More]

4 6

Stem ORPort protocol support
by Damian Johnson 07 Feb '18

07 Feb '18

Hi all. Over the last few months Tim and I have been collaborating on Python support for the ORPort protocol. With it you can download descriptors without a DirPort, and possibly fancier things in the future like full circuit construction. Tim put together a wonderful proof of concept called Endosome... https://github.com/teor2345/endosome ... and I just finished integrating it into Stem... https://gitweb.torproject.org/stem.git/tree/stem/client/__init__.py With stem.client you can … [View More]

3 4

[release] Onionoo 5.0-1.10.1
by iwakeh 07 Feb '18

07 Feb '18

Hi there! A fix for the most recent Oninonoo version is available at: https://dist.torproject.org/onionoo/5.0-1.10.1/ The changes [1] concern also the resolution of graph data: three months weights and bandwidth data are now provided in 24 hours detail. Deployment of the new version 5.0-1.10.1 finished successfully for all onionoo.torproject.org instances. The changes for bandwidth data might take another day to be visible. So, we need to have a little patience. Please direct … [View More]

1 0

[release] Onionoo 5.0-1.10.0
by iwakeh 07 Feb '18

07 Feb '18

Hi there! the new Oninonoo version is available at: https://dist.torproject.org/onionoo/5.0-1.10.0/ All changes [1] this time are supposed to make writing of bandwidth, clients, uptime, and weights documents independent of system time, which is a step toward making Onionoo instances serve the same data where possible. Other steps remain and will be addressed in future [2]. Deployment of version 5.0-1.10.0 will start at 13:00 UTC for all onionoo.torproject.org instances. It might cause … [View More]

1 0

Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory
by iry 05 Feb '18

05 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Thank you so much for the immediate feedback, teor! Could you please help me to review the requirements (TODO list) below: * %include /etc/torrc.d means parsing all the files in the directory * implement %include /etc/torrc.d/*.extension syntax * let Tor log each config file it loads * warn on potentially unexpected files * document *.conf as the recommend usage * document how to manually migrate from * to *.conf * recommend /etc/torrc.d/*.conf … [View More]

1 0

Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory
by iry 05 Feb '18

05 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi teor! > Could you please look at existing .d folders of any other projects > tell me what you think? Perhaps discuss this with Tor Project. > [...] From my quick search, it appears that the Debian feature > request is still open, and no other distro is using torrc.d yet. > But you should check, too. I went through all Tor packages listed here: https://trac.torproject.org/projects/tor/wiki/doc/packages and no distros … [View More]shipped a torrc with %include line enabled. I know Whonix will not use torrc.d before next stable version. I also did a grep -r -i "%include" on Tails source code and I do not think Tails has enabled it by default. nickm suggested proposed to create a new syntax to take care of the compatibility: > %include /etc/torrc.d/*.conf Here is my thoughts on this: 1. I agree that "[a]nybody who currently has a working setup will have it fail if we start requiring a suffix that they didn't know to provide", which is not good for compatibility. But, letting people still use or will be able to use a setting that is not recommended anymore seems also not to be a very good idea? Considering the potential danger of parsing all the files, shall we go a little bit aggressive? I would rather break people's current potentially dangerous settings. What do you think? 2. Since no distros I know has enabled this feature by default, I guess there are only a very small number of users has enabled this feature. Will an info in the release note saying "%include /etc/torrc.d/ will only pase files suffixed with .torrc files" be enough to inform them? Maybe we can even document the manual migration somewhere. 3. %include /etc/torrc.d/*.conf syntax is very flexible so that Tor does not have to decide which extension names should be parsed. 4. %include /etc/torrc.d/*.conf syntax explicitly says which extension name will be used rather than the implicit document. 5. But is it a good idea to make the syntax that flexible? For example, anon-connection-wizard will generate a torrc files in torrc.d directory, I (and maybe many other developers) prefer writing to a file that I can guarantee it will be parsed in most case. If I write to 40_anon-connection-wizard.conf but some people set to pase .torrc or anything else only, it will be not be very good? (I do not want anon-connection-wizard to touch /etc/tor/torrc) Finally, do you think it is a good idea to switch to the ticket for further discussion to avoid cross posting and high volume on @tor-dev? Thank you very much! Best Regards, iry -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlp4pFoACgkQoUtNvG3N 1TwSkRAAnBRytWCeP8ocCOJ0FmJZVq4ANznDWWBoYg+iaRPUMYbU/Tro0j7ljJMe snf0ji+Eu8DqTjg/HgmQ9gVuiJNWE7jfvnaAE7nDxeqd23J68ek5yHeIwonnaVPq IrWeCQDAAUUz42rAcoHBsy/tGS/kiq0OMf3yf6Pzq02UsQ4Ob46kD4ySNnirRXce a/mJG1zMXoAYnM84bKnm6bD4Gx5qiyK+O61e70z4b4ArPqRpxmfQoU5RAELMHAFU hq9JtdxN/FBvNq7NUOboAYcX1FdkWLLEaQXWB/sgtS94OvCIX0hfrtis0/UFPTe5 wQN1FQCFBpPkHOLuvszNln9WvPf0XSWqCDVdZh7Fd9GrELfrVwEJYC2+1rukPWZq U0ZJ0smDkdijHBc53i6+23175GyaQ+uMoSebouQ2vh9hbf2qx1EMnSFc5pSz8y5b eJgUA6WFZvcTgUFmwYpe3X2E3QcoYHD8UNoBZiD0ehXrWTcxScT0kWNcF06v3dhr 4Doo9wxDmF/ZusRrpyTRCZ5LsPCCL1spphxNqlCIm9MsfUCHBUbULBKn+uV2fNb6 4Xk2gu6eA258ZEfYDhottLpsk8V15Jx7F+Jz/W0zlL5OCwDzhPcG44C7OfEzeW5u h42Jw6YsQkAgGXnKzRG9lW7emVkLLhF0wlCSeWY8QxHGnxShdLY= =EnSw -----END PGP SIGNATURE----- [View Less]

2 1

onionoo: varnish 503
by nusenu 05 Feb '18

05 Feb '18

https://onionoo.torproject.org/details?search=123 > Error 503 Backend fetch failed > > Backend fetch failed > Guru Meditation: > Varnish cache server thanks for having a look -- https://mastodon.social/@nusenu twitter: @nusenu_

2 1

Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory
by iry 04 Feb '18

04 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > To be more precise, most tools accept files ending in ".conf". We > might want tor to accept ".conf" for consistency. > > I suggest we also accept files called "torrc", or ending in > ".torrc". This should probably also include files called literally > ".torrc". > Thank you for your suggestions, teor! I have updated it in the ticket. > Since this is a breaking change, we might want to check if any > distribution … [View More]

2 1

onionoo.tpo stuck at 2018-01-21 22:00
by nusenu 04 Feb '18

04 Feb '18

Hi Karsten, just wanted to let you know that the delta between relays_published and current time is unusually high. https://onionoo.torproject.org/details?limit=0 {"version":"5.0", "build_revision":"0bce98a", "relays_published":"2018-01-21 22:00:00", This is currently blocking ornetradar reports. thanks for having a look, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 11

Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory
by iry 04 Feb '18

04 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> Therefore, may I propose to let Tor parse only the files whose >> name ends with .torrc ? > > Yes, this is standard behaviour among many tools. > >> Or maybe even only parse number_filename.torrc for better >> consistency and for more clear priority order? > > No, this is counter-intuitive. It will confuse many users. It is > not how most other tools work. Thank you so much for the feedback, teor! … [View More]

2 1

Proposal: only parse .torrc files in torrc.d directory
by iry 03 Feb '18

03 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tor Developers, I have been testing and using the torrc.d feature for a while, and here is a potential improvement we may make. Currently, when using a torrc.d directory, for example: > %include /etc/torrc.d/ Every file in the directory will be treated and parsed as a valid Tor configuration file. However, sometime, this may not be what users and developers want. For example, users may use /etc/torrc.d/50_user.torrc as the place to … [View More]

2 1

Re: [tor-dev] No Control Socket when DisableNetwork 1
by iry 03 Feb '18

03 Feb '18

> My first suggestion would be > [...] > My second suggestion would be to get a Tor binary and run it yourself, > not as part of a package. If it works there, then you know that your > next steps are to figure out why your package isn't working for you Hi Yawning and Roger! Thank you so much for trying to reproduce the bug and teaching me on the generic Tor debugging steps! I agree with you that: > If you can get a minimal case reproducing the bug without a package, > … [View More]systemd, etc, in the picture, that's a great time to file a trac ticket. It turns out, to successfully reproduce this, we need: 0. set DisableNetwork to 1 1. use User option as part of the Tor configuration 2. run sudo Tor from a different user in a different group Here are the specific steps to reproduce it. I tested it on Debian Stretch but it should be distribution independent: user@host:~$ cat /home/user/my.torrc DataDirectory /tmp/tor ControlSocket /tmp/tor/control.sock ControlSocketsGroupWritable 1 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /tmp/tor/control.authcookie SocksPort unix:/tmp/tor/socks.sock user@host:~$ sudo /usr/bin/install -Z \ -m 02755 -o debian-tor \ -g debian-tor -d /tmp/tor user@host:~$ ls -ld /tmp/tor/; ls -l /tmp/tor/ drwxr-s--- 2 debian-tor debian-tor 40 Feb 3 18:19 /tmp/tor/ total 0 user@host:~$ sudo /usr/bin/tor \ -f /home/user/my.torrc \ --User debian-tor \ --DisableNetwork 1 There should be control.sock, but not: user@host:~$ ls -ld /tmp/tor/; sudo ls -l /tmp/tor/ drwx--S--- 2 debian-tor debian-tor 100 Feb 3 20:00 /tmp/tor/ total 8 -rw-r----- 1 debian-tor debian-tor 32 Feb 3 20:00 control.authcookie -rw------- 1 debian-tor debian-tor 0 Feb 3 20:00 lock -rw------- 1 debian-tor debian-tor 215 Feb 3 20:00 state To let Tor really open the control.sock, we need to reload Tor (yes, even though we just start it): user@host:~$ ps -A | grep tor 863 ? 00:00:00 xenstore-watch 927 ? 00:00:04 tor-controlport 11851 pts/0 00:00:00 tor user@host:~$ sudo /bin/kill -HUP 11851 user@host:~$ ls -ld /tmp/tor/; sudo ls -l /tmp/tor/ drwx--S--- 2 debian-tor debian-tor 120 Feb 3 20:01 /tmp/tor/ total 8 -rw-r----- 1 debian-tor debian-tor 32 Feb 3 20:01 control.authcookie srw-rw---- 1 debian-tor debian-tor 0 Feb 3 20:01 control.sock -rw------- 1 debian-tor debian-tor 0 Feb 3 20:01 lock -rw------- 1 debian-tor debian-tor 215 Feb 3 20:01 state I guess the reason Yawning was not able to reproduce it is because User option was not set: user@host:~$ sudo -u debian-tor \ /usr/bin/tor -f /home/user/my.torrc \ --DisableNetwork 1 [notice] Opening Control listener on /tmp/tor/control.sock I was thinking Tor fixing /tmp/tor/ to 2700 may be the reason, but then I cannot explain why this will work with /tmp/tor/ set to 2700: user@host:~$ sudo /usr/bin/tor \ -f /home/user/my.torrc \ --User debian-tor \ --DisableNetwork 0 [notice] Opening Control listener on /tmp/tor/control.sock Would you please share some insights on the this? For temporary workaround using systemd in Debian, I put this line in the [Service] section of /lib/systemd/system/tor(a)default.service : ExecStartPost=/bin/kill -HUP ${MAINPID} Best Regards, iry [View Less]

1 0

small fixes for the sources.list generator (and new options)
by nusenu 03 Feb '18

03 Feb '18

Hi, since the tor relay guide depends on that page and it has a few issues I made some small fixes to it: https://www.torproject.org/docs/debian.html.en Bug 25107: sources.list generator: remove yakkety (we do not offer packages for it) Bug 25107: sources.list generator: add Ubuntu Artful Aardvark (17.10) Bug 25107: sources.list generator: remove zesty (we do not offer packages for it) Bug 25107: sources.list generator: add nightly-master option Bug 24994: point to the … [View More]

2 3

stem support for v3 ephemeral onion services
by Micah Lee 31 Jan '18

31 Jan '18

Now that Tor Browser 7.5 is released and includes the tor 0.3.2 series, which supports next generation onion services, I would love to make OnionShare use these by default. Here is the issue [1]. OnionShare is written in python3 and relies on stem to communicate with the Tor controller. Although tor now supports v3 ephemeral onion services, stem still doesn't. Just take make sure, here's a quick test, with Tor Browser 7.5 (providing tor 0.3.2.9) open in the background, and using stem 1.6.0: ==… [View More]

4 5

Starting with contributing to Anonymous Local Count Statistics.
by Aruna Maurya 31 Jan '18

31 Jan '18

Hey! I was going through the Tor Volunteer page and came across the Anonymous local count statistics project. As a student it would be a great starting point and an even bigger opportunity to get a chance to collaborate and learn in the process. I would like to contribute to it, and would love to start as soon as possible. It would be great if someone could guide me through. Thanks for your time!! -- Regards, Aruna Maurya, CSE,B.tech, Blog <https://themindreserves.wordpress.com/> | … [View More]

2 1

website patches for new Tor relay guide sidenav entry
by nusenu 30 Jan '18

30 Jan '18

Hi Silvia, I submitted a (trivial) patch (in #24881) to add links to the new tor relay guide on the website and to remove previous guides that have been merged into the new guide. I noticed that since than new commits have been merged and these patches will probably no longer apply cleanly. I will try to ensure they apply (rebase) shortly before you have time to look at them if you can tell me approximately when that will be. thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 2

non-anonymous ephemeral onion services with stem
by Micah Lee 30 Jan '18

30 Jan '18

The stem documentation for create_ephemeral_hidden_service [1] says: "Changed in version 1.5.0: Added support for non-anonymous services." But I can't figure out to actually use this feature. There doesn't seem to be a new argument to say if you want your onion service to be non-anonymous. It also says, "Changed in version 1.5.0: Added the basic_auth argument." But there's a new basic_auth argument you can pass into the function to use that. [1] https://stem.torproject.org/api/control.html#stem.control.Controller.create…

5 12