- tor-dev - lists.torproject.org

Bifroest's sanitized bridge descriptors available from CollecTor in 48 hours from now
by Karsten Loesing 31 Aug '16

31 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, if you're not using CollecTor's sanitized bridge descriptors for anything, you can safely ignore this message. As you may know, there are currently two bridge directory authorities in the Tor network, Tonga and Bifroest, and Tonga will go away some time this weekend. You can fetch sanitized versions of Tonga's bridge descriptors here: https://collector.torproject.org/recent/bridge-descriptors/ We're also now ready to provide sanitized versions of Bifroest's bridge descriptors. The only differences to Tonga's descriptors are: - Statuses will have Bifroest's fingerprint in their file name rather than Tonga's. Example: https://people.torproject.org/~karsten/volatile/20160829-164232-1D8F3A91C37… - There will be two "concurrent" statuses published by Tonga and Bifroest this week, containing two distinct sets of bridges. I'm holding back Bifroest's descriptors from CollecTor for another 48 hours or so to give you time to prepare for this change. After all, you might have written your code under the assumption that there's just a single bridge authority, and the above change might confuse your code and break it. Everything will be on CollecTor in 48 hours from now. All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJXxHytAAoJEC3ESO/4X7XBMfAIAKXADVnMGK5rYmbZN5ymF2M8 IbFc/6VWV+CoUdss868Dp5/Y3huE6SgFXCe3A+R+jCg5Od8rIiWKEfNvVeLEXpU1 DtuYNAq3vlhVhHTOdWmCz2uRVeWNddb12RDa+H55QtGHC4JC8HP9PRSN+lLj5fBr YBuKvLAWfMOsfdAqVJwHmmhtORPag7wL2NWmmk/y4j9JCzQ//NmUv3CMdIQm+j98 pM5jwI6ogiec2f/Nbij3eSJHCAhHKuL5TKR6E+//TE/s4ZGBKDPxkw+w/PdQrViC A3RgDVm7sqrjKkm2jWHVEuTa36QdzBgpV6vH1tEmTrHTz7Epre3MVFwKR607LBM= =gXT3 -----END PGP SIGNATURE-----

1 1

metrics-lib/DescripTor 1.4.0 is released
by Karsten Loesing 31 Aug '16

31 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, we just released metrics-lib/DescripTor 1.4.0: https://dist.torproject.org/descriptor/1.4.0/ - From the change log: # Changes in version 1.4.0 - 2016-08-31 * Major changes - Add the Simple Logging Facade for Java (slf4j) for logging support rather than printing warnings to stderr. Applications must provide slf4j-api-1.7.7.jar or higher as dependency and can optionally provide a compatible logging framework of their choice (java.util.logging, logback, log4j). * Medium changes - Add an alpha version of a DescriptorCollector implementation that is not enabled by default and that uses CollecTor's index.json file to determine which descriptor files to fetch. Applications can enable this implementation by providing gson-2.2.4.jar or higher as dependency and setting property descriptor.collector to org.torproject.descriptor.index.DescriptorIndexCollector. * Minor changes - Include resource files in src/*/resources/ in the release tarball. - Move executable, source, and javadoc jar to generated/dist/. Happy descriptoring! All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJXxp6UAAoJEC3ESO/4X7XBUF8IAMuIPxoCkt9FR6LolUmuyk3I +eElyry5r8jUGDiBOxx0TWrYxr6ZrvxOD6lxzvG0a/nfAF+cdELJyNE+1+GiTku2 rgM/1NcxqGq6yBzxMFOZXPv1VG35LmpFtQUnxZR5Ij8x/p3SweMlbHUAVShSQZT2 tuRi32YCBZyH8XgD65XAak0SZ7co7aMZOORsixymFYW2oRYOxOkARX4sA4AfA4ED Nkqwa4fhX3b4uIshbzpifXm0ACkAxEUwewLS/g6vkKcn0a0tS6DC3mDrzIOAvF8v VTLghyZKbuWWuGZAlLEDhyHmo3/Afy6ETb1cFy/lvJUVnu/W8P4sbRnQrfvVJ/s= =Ugsq -----END PGP SIGNATURE-----

1 0

Requiring p lines in consensuses
by Sebastian Hahn 31 Aug '16

31 Aug '16

Hi there, Karsten and I have been working on metrics-related tasks and one thing that's got a potential to cause us pain going forward is that of "p"-lines in consensuses. Tor has added them with consensus method 5 but only declared them to be optional. In practice, every consensus ever produced that used method 5 or later has added these lines, and I'd like to require them to be included going forward. The reason is that without looking at the consensus method, there's an ambiguity wrt exits: A missing line either means "reject 1-65535" (method 5 or later) or "no information" (anything before that). I believe this should cause no compatibility issues and wouldn't require a new consensus method. Is there some reason against doing this now? Cheers Sebastian

1 0

Alternative Implementations of Tor
by Alexander Færøy 29 Aug '16

29 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Over the past year I've been hacking, on and off, on an implementation of Tor in the Erlang programming language. The project started out after I met Linus Nordberg at the Erlang User Conference in the summer of 2015 - -- a couple of weeks before the CCC Camp in Germany. Linus and I discussed what it would take to get a very basic implementation of a Tor relay up and running in Erlang. The project has been named Talla, which is still open for change -- especially if it collides with an already established project within the wider Tor development community. I was unable to find any name clashes myself, but I may very well have overlooked something. The parts of Talla that is implemented in "pure" Erlang is going to be licensed under a two-clause BSD license. Talla also contains a "module" which is using Tor's ed25519 ref10 implementation (Thanks to Yawning for a great amount of help there) -- that module is licensed under the same license as Tor itself. I'm now at the point where things are slowly starting to take form. The important pieces of the code have so far been kept available only to a tiny group of close friends that I trust not to share the code until I, and possibly other people, considers that the code is stable enough for the wilderness of the wider internet. There is, to my knowledge, currently only one implementation of Tor that is actively in use on the production network, which is the C implementation. I'm aware of a Haskell implementation made by Galois, which to me mostly seemed like it was designed to be building blocks for writing more specialized clients and doing research with the Tor network. Last time I looked, the Haskell implementation's main function was doing a DNS lookup through a circuit within the Tor network and then quitting. I was also told there had been an implementation in Go that have had activity on the production network, but that project was abandoned by its maintainer. In general I'm a bit uncertain about the "best practices" of dealing with a third party Tor implementation, which Talla is. I'm writing this email to receive suggestions, comments, and possibly creative ideas about the following: 1. What is the general criteria set from the Tor project's perspective on when it is acceptable to make alternative Tor implementations available to the general public? I'm currently testing Talla using Chutney with a mixture of NTOR and pre-NTOR Tor daemons running (inspired by one of the configuration files in the Chutney repository, which referred to a 'tor-old' binary). My current plan is to stabilize Talla further until my gut feeling is that I can try to announce a single, middle, relay to the production Tor network. This relay will, of course, have a platform-string set to something easily identifiable like "Talla 0.0.1 (...)" and the contact-string set to a valid method of reaching out to me with, in its announced server descriptor. I will closely monitor that things are going as I expect and probably turn it off shortly after the test, when I have seen that my code isn't too "crashy" -- this will most likely be repeated a number of times until I'm satisfied with the results. Could I do more to ensure that the people caring for the network as a whole wont fear me pressing the start-button here? 2. I will not do any classical releases (as in packagable .tar.gz) until I'm past the point where my gut feelings are telling me that my code is reasonably stable for the production network of Tor. I will, in a very visible location, request that no distribution developers makes any packages of the code until there is a release. I think this is already the norm, but I guess being explicit won't hurt. 3. I will write, also in a visible location, a warning that the code is not production ready and that people should probably stick to running a Tor relay using the official Tor daemon and point to the installation instructions on torproject.org. 4. Not have any installation documentation and hope that Erlang is still an esoteric enough language to make people pass by without trying :-) 5. Talla will not have any references to the directory authorities that are currently used for the Tor production network. This means that anyone who is interested in running Talla will have to explicitly set the directory authority servers in Talla's configuration file. This will allow people who want to toy around with it together with Chutney to be easily able to do that. Why am I asking all these questions now, when I could just wait until Talla is ready? In two weeks there will be a smaller hacker camp in Denmark, named BornHack, where I was planning on giving a talk on the development of Talla, the design of the Erlang application, some of the many refactoring periods there have been, general information about how Tor works, and the testing of Talla. At the same time of the presentation I want to make all of the code for Talla available for the audience and public to see even though it at this point is not ready for "production usage" on the public Tor network. I hope this email will also allow us to discuss the wider concept of a network where there exists multiple implementations and the consequences of that. It might be there are other people hacking on a Tor implementation in their favourite language :-) I'm also on IRC as 'ahf' if anybody wants to talk about things regarding Talla that is outside of the scope of this email. Thanks you! Cheers, Alex. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXtHtlAAoJEPm8L+IrCM6PNl4P/08HCGnEpLADudaul9KX4bzL OqcygCP6AXpFUZdUqsD+hgPRgi97NYaNZas/hWimQyye3OfLw4EH29lukGiBrIZu Fp+bT2CAsan8Nn+Vb3rH0em1PPOyXYJ/qhYrXex/CPk5kY7CIatbwau9AgwylAKs 8G3wz364EQaAwq5v4BVTieenFxtNXfnjwtlPkNhtJUgRDwrj16v2IqwN1C6nIq2p E86Vok4ToWKwfzIshf2wESSGWHZ+K9bpZs+e1GnSkY4VgwpKE1Swp/8IhIlxa843 KO4EknByZIWqZrEORCd43nok88hW8tpbnuoMCE5HGMJzw/KTwQrSiS794cAnyhYt 6yokEUO3JdwRuJxLPzmLZc8tBniBaKuGfRbqC7XAurJkgq+UgLukgYWnlyvHlap+ RZaNpMqFQf8grMHWGd6ffxYzAcIc+935XN4D54Ua17seIpDHnKGKS04ZmKwBeCxy myafcqSxJsNrqYEN40QrtYdgU0zv74S75uU/DHAHcOcaPyAy5yHGAqAdOeGvtpV5 6/VAQDwbOPncfIntoU8FUjKcpKJBn5csltuknwDiWKFYLfAVqVawMYO2Ef12hDul 7SuqOksSL2Yx59m/0Bu8i0QARxZBw8x8TzuQ7RJkNmDeTR17ugDOIaBKV1Se9fgS JaHsOgLd/G0T7S4PT5vQ =IeQJ -----END PGP SIGNATURE----- -- Alexander Færøy

4 3

Some information about Tor relays
by Liu, Zhuotao 26 Aug '16

26 Aug '16

Hi Folks, This is Sky from University of Illinois. Currently we are working on research project related with Tor. To help us to better design and evaluation our proposal, we need some information about the Tor relays that is currently unavailable from the Atlas. Thus, if someone who operates Tor relays could provide us such information, your help will be greatly appreciated. :) We hope to have an estimate about computation capacity of Tor relays. For instance, how many circuits a relay can maintain when its CPU is driven to about 100%? On average, how many circuits are maintained by a busy guard and what the CPU utilization is. These kinds of information would be really helpful. Further, in Sep 2013, Tor saw a spike in its clients. https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients The suspicion is that a botnet used Tor as its C&C channel. Is there any data about the relay utilization during that time? For instance, how many more circuits a relay had to maintain during that time? Thanks a lot for your help. :)

4 7

Proposal 272: Listed routers should be Valid, Running, and treated as such
by Nick Mathewson 26 Aug '16

26 Aug '16

Filename: 272-valid-and-running-by-default.txt Title: Listed routers should be Valid, Running, and treated as such Created: 26 Aug 2016 Author: Nick Mathewson Status: Open 1. Introduction and proposal. This proposal describes a change in how clients understand consensus flags, and how authorities vote on consensuses. 1.1. Authority-side changes Back in proposal 138, we made it so that non-Running routers were not included in the consensus documents. We should do the same with the Valid flag. Specifically, after voting, if the authorities find that a router would not receive the Valid flag, they should not include it at all. This will require the allocation of a new consensus method, since it is a change in how consensuses are made from votes. In the most recent consensus, it will affect exactly 1 router. 1.2. Client-side changes I propose that clients should consider every listed router to be listed as Running and Valid if any consensus method above or higher is in use. 2. Benefits Removing the notion of listed but invalid routers will remove an opportunity for error, and let us remove some client side code. More interestingly, the above changes would allow us to eventually stop including the Running and Valid flags, thereby providing an authority-side way to feature-gate clients off of the Tor network without a fast-zombie problem. (See proposal 266 for discussion.) A. An additional possible change Perhaps authorities might also treat BadExit like they treat the absence of Valid and Running: as sufficient reason to not include a router in the consensus. Right now, there are only 4 listed BadExit routers in the consensus, amounting to a small fraction of total bandwidth. Making this change would allow us to remove the client-side badexit logic. B. Does this solve the zombie problem? I tested it a little, and it does seem to be a way to make even the most ancient consensus-understanding Tors stop fetching descriptors and using the network. More testing needed though.

1 0

Not enabling IPv6 on check.torproject.org?
by Frederic Jacobs 26 Aug '16

26 Aug '16

Hello Tor-Dev, When opening Tor browser today, I opened check.torproject.org <http://check.torproject.org/> and got a really confusing message <https://www.fredericjacobs.com/blog/img/tor/ipv6TorCheck.png>. My assumption is that the circuit had an exit node that had (possibly multiple) IPv6-enabled, in addition to it’s IPv4. When the exit node connected to the exit node, it did so over IPv6 since check.torproject.org <http://check.torproject.org/> has IPv6 addresses. ~ ❯❯❯ host check.torproject.org check.torproject.org is an alias for chiwui.torproject.org. chiwui.torproject.org has address 138.201.14.212 chiwui.torproject.org has IPv6 address 2a01:4f8:172:1b46::abba:20:1 That’s a scary warning to get in Tor browser. Any reason chiwui.torproject.org <http://chiwui.torproject.org/> has an IPv6 address? Can it be disabled to avoid having people (unnecessarily) freaking out over this warning? Thoughts? Best, Frederic

6 6

Can't bootstrap with one guard?
by teor 26 Aug '16

26 Aug '16

Hi All, It looks like Tor currently needs at least two EntryNodes to bootstrap. It hangs when loading descriptors. See https://trac.torproject.org/projects/tor/ticket/19989 This leaves me concerned that we won't be able to switch to one guard. (It's also somewhat annoying when I'm trying to test if each of my relays is working correctly.) Did we have plans to switch to one guard any time soon? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org

1 1

[GSoC] Tails Server - Final status report
by segfault 24 Aug '16

24 Aug '16

Hi everone, the GSoC ends this week. My goal was to implement the basis of the Tails Server, which should include a GUI and a CLI to install, configure and start onion services in Tails. I implemented a prototype which meets this goal. There are nightly images [1] of Tails including this prototype and the code is available here [2]. This is not yet a call for testing, but there will be one at some point. [1] http://nightly.tails.boum.org/build_Tails_ISO_feature-5688-tails-server/bui… [2] https://gitlab.com/segfault_/tails/commits/feature/5688-tails-server The current prototype does not meet all the requirements for shipping it in Tails yet (which was not the goal of the GSoC), but it won't require too much additional work. These are some things that still need to be done before including Tails Server in Tails IMO: - Implement client authentication - Run as non-root user - Fix some UI issues - Test performance on low end hardware - Find and fix bugs - Improve user documentation - Write design documentation - Write tests for Tails' test suite I will definitely keep on working on this and try to finish it ASAP. I don't know exactly how much time I will be able to spend on this from now on, but a first version of Tails Server could be shipped with Tails in early 2017 or even late 2016. Cheers

2 1

CollecTor Release 1.0.1 bugfix
by iwakeh 22 Aug '16

22 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! This is the first bugfix release of CollecTor. It prevents an out-of-memory error. So, it's advisable to upgrade immediately: https://dist.torproject.org/collector/1.0.1/ More details can be found here [0]. Cheers, iwakeh [0] https://trac.torproject.org/projects/tor/ticket/19913 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAle6zlYACgkQsANAxTOj/aYzrwD8CgPMtiOyd6qkPGryA40VDb5R fZG6yhpKKjLYl3RLErMA/3NNnIDi+IMtd2j4KevlAycmj3zFw/rxO0AOXZqsdbid =RiXj -----END PGP SIGNATURE-----

1 0