- tor-dev - lists.torproject.org

Priorities for Onionoo development
by Karsten Loesing 25 Feb '15

25 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi iwakeh, cc'ed Tor devs, now that we're down to 0 defect tickets in the Onionoo component (not counting that one ticket in needs_review that I hope to resolve before the weekend), ... time for a little applause... I went through the 20 open Onionoo enhancement tickets in an attempt to categorize and prioritize them. Mind going through the list below and commenting on summaries and priorities? And is there a ticket that you'd want to work on? Here's the list, where (--) means low priority and (++) means high priority: === Functional enhancements, user-facing features === #9778 Adding votes documents to Onionoo (-) Processing votes and adding a new document type are major enhancements. The result might turn out to be really useful, but this takes quite some effort. Not super urgent, I'd say. #11041 Add new document type with monthly relay and bridge statistics to Onionoo (-) This is a major feature, and I didn't hear back from the people who originally suggested it. I'd say put on hold until somebody really wants this. #11430 Add new field last_running for "seen in a network status with the Running flag" in addition to last_seen for "seen in a network status" (-) Not many people will care about this distinction, though it's technically a good thing to make it. #11432 Start a bridge's uptime history when it was first listed in a status Similar to #11430, not many people will care about this. But it's still a good idea. #13137 Historical data (+) Without reading the whole ticket, this sounds worthwhile, though time-consuming. #13424 Add new `descriptor` parameter that returns relays or bridges by digest of recently published descriptors This feature would only be used by a very small subset of people, though those people help debug the Tor network. Maybe this isn't terribly difficult to implement. #13425 Add new document type `debug` that includes digests of recently published descriptors and statuses they're referenced from (--) Unclear if people would actually use this. Lowest priority. #14879 add platform search support to onionoo (+) Useful feature, but we should first think about related features and whether we should add them at the same time. === Refactorings, documentation, non-functional enhancements === #11573 Ponder using a database for Onionoo rather than keeping indexes in memory and contents on disk (--) I don't see the clear advantage of switching to a database. There's the risk that it will not perform (much) better or even worse than the file system based design. In any case, we can easily spend lots and lots of hours on this, and even if we're successful, there's no/hardly any visible change to users. Lowest priority. #12944 onionoo protocol/client api and base implementaion (-) I'm unclear what the benefit will be. And unfortunately, patches have aged quite a bit by now. #13003 Figure out a better strategy to avoid concurrent Onionoo executions (+) Unclear what's left to do here, but the summary sounds reasonable. #13080 Add Ant tasks for measuring coverage, dependencies, etc. (++) Without reading the ticket body, this would be great to have. #13088 Versioning and Releases (++) Sounds like a great thing to do, but I need help with this. #13334 improve DetailsDocument (-) Subticket to #12944, same priority. #13362 Make Onionoo's logs more useful (-) Unclear what's left to do, though making logs more useful sounds good. Depending on how much time we can sink into this, though. #13561 logging documentation (-) Seems useful, but if we start documentation logging configuration, we'll soon write much more documentation. This can of course be useful. But it's a huge time sink. #13562 additional logging for backend and frontend components (-) Better log statements would be great, but see the concerns about related tickets. #13600 Improve bulk imports of descriptor archives (+) We're in a good position to complete this ticket. And while it only affects very few people (Onionoo operators), it's worthwhile. #13616 define jmeter testcase(s) ant ant task(s) (+) Sounds useful to have some baseline data and then see how performance changes as new features are added. #14201 Configure out/ directory path somewhere else than in web.xml. (+) Sounds trivially useful. And here's the Trac query that this list is based on: https://trac.torproject.org/projects/tor/query?status=!closed&status=!needs… By the way, thanks for all your hard work by submitting and reviewing Onionoo patches! Many people use your work every day without even knowing it. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJU7ebnAAoJEJd5OEYhk8hIUOYH/3AP2iu8hnCYtbcDOSkzqbDT rSe/S5MewtrRlD4cnZID/TqGXGZLJofWbd4Ly4SOg0QpoT8uq47k/vmbeeOBXSqx O3Qxu/e7L9z8/NJeuym3nwTAcFnIQv7K1JkqvPSyB8wrMFhJe+mll+UHS38f5C4z dKdCLs5gsmGJljqbr17tMr2y0hm38u1ID8lzlqmU3H/vI+5dvKK7DPfdsRNLbvmc tA5ATufehYya3xbHJPy8K9W0P706n3Dg4qHBrZ2AnxB4mmX/k3x842WJhnIYapyI kPiM2i2RVdumZA91kHUEu2dYMY0P3OzJK3K9cn9eNFtxMhnMmI1zttkOsIg7mWw= =ZHaC -----END PGP SIGNATURE-----

1 0

Hello, I am a Tor user in China.
by Li Xiaodong 25 Feb '15

25 Feb '15

Hello, I am a Tor user in China. When will StegoTorus be deployed on Tor software? Thank you very much.

1 0

Tor Project Idea for GSOC 2015
by Gautham Nekkanti 24 Feb '15

24 Feb '15

Hi, I am Gautham (icodemachine from IRC and TRAC). I am willing to participate in GSoC 2015. I was brainstorming for project ideas and thought of this useful project idea. I want to put forward a project idea of Simple analytics tool for HIDDEN service providers. Although, there are already thousands of third-party traffic statistic tools, most of them require javascript and just defeats the whole purpose of server anonymity. This project is a little similar to Arm, instead it involves in listening how many users are connected to our site and parsing it. Advanced metrics like IP addresses of visitors, countries, e.t.c. wouldn't be available as it is pointless in our case (Since the IPs reflect the IPs of exit nodes). So, it basically displays the number of visitors and a few other metrics. Historic data will be presented graphically. The data will be accessible through a localhost website and Historic data would be stored in a local database. Although, it is not nearly as advanced as other statistic tools, it would still be an essential tool for Hidden service providers to analyze their traffic figures. How would it be? Please share your views. Thanks, Gautham

4 3

Tor 0.2.6.x now has its own branches
by Nick Mathewson 24 Feb '15

24 Feb '15

Hi, all! Work on the Tor 0.2.6.x release series will proceed on the "maint-0.2.6" branch; releases will be build against "release-0.2.6". The master branch new has Tor 0.2.7.0-alpha-dev. cheers, -- Nick

1 0

Fwd: Orbot v15 alpha 4
by Nathan Freitas 23 Feb '15

23 Feb '15

----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Orbot v15 alpha 4 Date: Mon, 23 Feb 2015 13:17:26 -0500 More progress on better bridge support and "full device" VPN mode... and a bit of a UI update, too! APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-4.apk ASC: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-4.apk.asc On the bridge front, we now support QR code scanning, since the https://bridges.torproject.org/ site now displays bridge info as QR codes optionally. You can also display your current bridge config as a QR code, so that your friends can easily scan/set it up for themselves. To use the "Meek" bridge, you just turn on bridges w/o having any config (press the new [BRIDGE] button on the main screen), and it will use the Meek Azure bridge by default. If you set the config info to 1 you can use the Google Cloud bridge, 2 = Azure and 3 = Amazon AWS. If you want to learn more about why you would send your Tor traffic through Google, Microsoft or Amazon, read here: https://trac.torproject.org/projects/tor/wiki/doc/meek Finally, the VPN mode is working well, but you can't use bridges with VPN mode together yet... still trying to make that work smoothly. ***** * Better Bridge Support fb9a6c9 support for sharing/display bridge config as QR code this is needed for sharing of bridge data between people in the same phy 068cd05 more bridge and proxy configuration clean up 31053ad add support for scanning QR codes for bridges f22978e update pluto bff6d0f add support for meek PT 266c297 update to latest pluto for meek-client 22e75a3 update pluto to latest 431dff5 remove integrated pluto code * Full Device VPN Mode dd09c6b tuning boot code to work with VPN b2ec768 more work to get bridge VPN mode to work f2490d9 handle all exceptions in socks proxy 9c77526 move HTTP VPN bypass proxy to 9998 096eae7 implementing http server for meek-client VPN bypass 1e5651e improve VPN clean-up code a2662c3 improve VPN activation c220ec9 re-enable DNS settings after you start Tor 6832363 use IP instead of "localhost" name 7f42265 launch the internal or system browser depending upon VPN mode 1852cde enable local DNS listen on 10.0.0.1 for VPN service also add support for stopping VPNBuilder instance ec4350e update VPN to toggle button 9467d7d clean VPN proxy settings before startup d63d10d massive cleanup of merged code from Ony fork removal/comment out of LoggerFactory log system a78e458 Merge branch 'ony-dev' into v15-dev 5c80572 Merge branch 'master' of https://github.com/SuppSandroB/Ony into ony-dev 4c49822 clarify vpnprotect code and add basic debug log 1464901 added badvpn as local folder 72a0173 delete as it should not be as subproject 90db557 clone of badvpn for dns fix 1472b4e some missing files added to git repo 08c220f clean up VPNBuilder setup code 91a72ef add in basic debug output fb3e27b more clean-up of VPN service code * Integrated Orweb simple browser 5a8aa88 add new gitmodules for orweb and pluto support 40b8f48 set to lib_orweb branch -- Nathan of Guardian nathan(a)guardianproject.info

1 0

OONI weekly dev meeting today Monday 23rd of February 18:00 UTC
by Arturo Filastò 23 Feb '15

23 Feb '15

Hello Oonitarians, We have skipped the last two weekly dev meetings because of various necessities, but I am going to suggest we try and make it today. There are a lot of interesting things to discuss and think about together. These are the topics that I have in mind, feel free to append to this list if you think that there is something else: * Discuss the outcome of the "Future of OONI" thread: https://lists.torproject.org/pipermail/ooni-dev/2015-February/000246.html * Updates on the migration of the pipeline * Discuss how to get 1.2.3 released on debian * Updates on libight and iOS integration * Finishing the bridge reachability study The meeting will happen as usual on the #ooni channel on irc.oftc.net at 18:00 UTC (19:00 CET, 13:00 EST, 10:00 PST). See you soon! ~ Arturo

1 0

Re: [tor-dev] Tor Project Idea for GSOC 2015 (icodemachine)
by Gautham Nekkanti 23 Feb '15

23 Feb '15

Thanks Paul for your valuable input. Yes, i think tracking the Geo-Location (country) would also be useful to understand the network although it might not benefit the onion service provider. Hope someone would mentor me on this. Cheers, Gautham

1 0

Shadow v1.10.1 is released
by Rob Jansen 20 Feb '15

20 Feb '15

Hi all, In case anyone missed it, I released a new version of Shadow last week. Download links and the release notes are available on the release page here: https://github.com/shadow/shadow/releases/tag/v1.10.1 I've also copied them below in markdown for your convenience. All the best, Rob ==== I just tagged `Shadow v1.10.1`, and new links are available to [download the release][dlpage]. This is a major release, and includes: + the Tor plug-in is now split into [its own github repository][shadow-plugin-tor] for better modularity + a new Bitcoin plug-in that can run the Bitcoin software in Shadow, in [its own github repository][shadow-plugin-bitcoin] + a new traffic generator plug-in that can model client behavior using actions in a dependency graph format (replaces the old filetransfer plugin, which moved to [shadow-plugin-extras][shadow-plugin-extras]) + updated [Shadow wiki][shadow-wiki] and [Shadow website][shadowweb] refresh, new [Tor wiki][shadow-plugin-tor-wiki], and new [Bitcoin wiki][shadow-plugin-bitcoin-wiki] + several enhancements to support running Bitcoin, including support for the `timerfd` timer interface, `AF_LOCAL` local Unix sockets, and more accurate handling of socket and file descriptors + new scripts for parsing stats from shadow log files and visualizing them + other core improvements and [bugfixes][r110issues] Happy simulating! [dlpage]: https://github.com/shadow/shadow/releases/tag/v1.10.1 [shadowweb]: https://shadow.github.io [shadow-wiki]: https://github.com/shadow/shadow/wiki [shadow-plugin-tor]: https://github.com/shadow/shadow-plugin-tor [shadow-plugin-tor-wiki]: https://github.com/shadow/shadow-plugin-tor/wiki [shadow-plugin-bitcoin]: https://github.com/shadow/shadow-plugin-bitcoin [shadow-plugin-bitcoin-wiki]: https://github.com/shadow/shadow-plugin-bitcoin/wiki [shadow-plugin-extras]: https://github.com/shadow/shadow-plugin-extras [r110issues]: https://github.com/shadow/shadow/issues?q=milestone%3Arelease-1.10.0+is%3Ac…

1 0

Re: [tor-dev] [tor-assistants] Researching Tor for Master's Thesis
by Florian Rüchel 18 Feb '15

18 Feb '15

Hi everyone, I am attaching the conversation from the assistants list over. Here is the TL;DR: I want to write my master's thesis on Tor, preferrably on a topic that has to do with Hidden Services and/or Cryptography in Tor. I have followed George's recommendations and read through some of the sources provided. In the end, several topics seem appealing to me, but before moving on I'd like to get some feedback from you guys on whether you'd consider the topics worth researching or even have some additional ideas. HSDir tracking: I have taken a look at the idea of PIR ( https://en.wikipedia.org/wiki/Private_information_retrieval) and the problem associated with getting HS descriptiors. I have only looked at the theory of PIR so far and not yet an idea of how this can be accomplished (and to what extend) in practice. Certificates for HS: I find this topic particularly interesting and have followed the discussion. The general concept seems like a great thing to achieve and it could actually outperform the regular SSL/CA infrastructure stuff as it could remove the need for CAs. Unfortunately, this seems something that is not extensive enough to warrant a whole thesis. If you guys think otherwise, please let me know. Tor with mix features: Tor has the explicit goal of being a low-latency network. However, there are several protocols where high-latency would be acceptable. I liked the idea of high latency HSes (https://lists.torproject.org/pipermail/tor-dev/2014-November/007818.html) I'd like to know what you think about this idea being viable. It would have the advantage of being very flexible from just a theoretic evaluation down to a real implementation so I could adjust this to my time. But only if this is actually desired so it does not need to stay theoretic. I think it would be very interesting to evaluate whether this can improve or hurt anonymity of low-latency users, as well. Traffic confirmation attacks: This is here more or less for completeness. I know this topic is open for several years and would be one of the most powerful countermeasures to deploy but unless someone has started on something that I could build upon, I don't see myself coming up with something useful here. Guard discovery attacks: I have only read roughly what these attacks are. I'd like to know if it would make sense to take a deeper look here, i.e. you think extensive research is needed on that topic. Improving crypto for HSes: The blog entry on HS (https://blog.torproject.org/blog/hidden-services-need-some-love) vaguely states that crypto for HSes could be improved. However, the article is over a year old and I know the new rend-spec-ng exists, so I'd like to know whether there's anything here to work on. I have a fairly good background on cryptography, so I'd like to help here if help is needed. Cryptography: There's two proposal ideas, one from 2010 (https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-cr…) and one from 2011 (https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-ne…) which builds on that. Has some of this been addressed? Is this still being worked on or just leftover that has already been integrated to the desired level? Would an analysis of the cryptography used in Tor make sense to you, i.e. building on those documents reviewing where and how Tor uses cryptography to secure its operations and evaluating the methods used? Onion addresses: I took a look at several approaches around censorship-resistant lookups, e.g. the GNS (see George's recommendation below) and Aarown Swartz's proposal on squaring Zooko's triangle by achieving all three properties. I think it would be a cool thing if it were actually possible to improve onion addresses to be human-readable, especially when they get longer by using bigger keys in the future (since 80 bit won't suffice). I don't know if this is actually possible (I see some issues on Aaron's proposal and Dan Kaminsky confirmed them) but working out a scheme that makes handling the names easier for users while not sacrificing the security would help a lot, I think. This would be the bigger topics I have found on which I could see myself building a thesis. I also stumbled upon smaller research questions (e.g. whether running a bridge/relay is good, bad or doesn't make a difference for anonymity) but none of those warrant a full 6 month thesis so I discarded them for the moment. If you could take the time to evaluate my ideas and let me know what you think, I'd greatly appreciate that. The hardest thing here as an outsider is to assess the current situation and figure out where work is actually needed and where problems/issues have already been addressed so any help from you guys would really help me. Thanks in advance & Regards, Florian Rüchel P.S.: George: > I'm about to relocate, so my reply will be short! Come and find us in > CCC for more. Unfortuantely, I don't know what you mean by CCC :( > Ah, I'm also a fan of the FluxFingers team :) Great! Have played some CTFs for yourselves, then? Are you member of a team? Thanks for your quick reply, it has helped me a great deal moving forward on this project. On 12.11.2014 23:15, George Kadianakis wrote: > Florian Rüchel <florian.ruechel.tor(a)inexplicity.de> writes: > >> Hello everyone, >> >> I am about to write my master's thesis and am evaluating Tor as my >> research topic. I have read through several documents (including the >> Ideas page of the research page and the Research page on the Volunteer's >> page). I also read "Hidden Services need some love" >> (https://blog.torproject.org/blog/hidden-services-need-some-love) and >> especially followed the section on cryptography (reading both proposals) >> with great interest. >> >> Before diving into more of those documents that are available, I noticed >> you encourage people to contact you through this list should they wish >> to conduct research. Right now I am in a very early state as I have not >> chosen a topic yet. In my choice I want to do something that benefits >> the Tor network, satisfies my professor and involves topics I generally >> care for. >> >> As noted above, I took particular interest in Hidden Services and >> general cryptography used by Tor. So if possible, I would like to have >> those two (or one of those topics) to focus my thesis on. Of course, I >> need to define my topic in such a way that it fits my time schedule >> (half a year, full-time) and that my professor accepts it. >> >> Now, before moving any further I'd like to know if there are any further >> documents I should read that are more up to date than the documents >> indicated above (especially the crypto specs are from 2010/2011 so I >> don't know how far the network has moved here). It would also be >> interesting to know whether some of the issues described for Hidden >> Services are already addressed and whether my research would be better >> directed somewhere else. >> >> I would be glad if you could take the time to respond to my request so >> as to help me define my topic better. >> > Greetings, > > I'm about to relocate, so my reply will be short! Come and find us in > CCC for more. > > I'd first suggest you to join and skim over the [tor-dev] mailing list: > https://lists.torproject.org/pipermail/tor-dev/ > Especially this month there has been an increase of threads about > hidden services, so I'd suggest you to check it out. > > I'd also suggest you to read the recent blog post about the attacks > against HSes: > https://blog.torproject.org/blog/thoughts-and-concerns-about-operation-onym… > > The blog post offers plenty of material for research, since it lists > various attacks and issues with the security of HSes that we need to > fix and would definitely benefit from further thinking. Check the > guard discovery [tor-dev] thread for example. > > Also check this recent thread: > https://lists.torproject.org/pipermail/tor-dev/2014-October/007642.html > which is part of figuring out work for a funded project. Most of those > tasks are not very interesting for you, but you can find deeper > research questions in some of them. > > Another guy recently did his thesis on HS scaling: > https://lists.torproject.org/pipermail/tor-dev/2014-April/006788.html > > There is also this stuff: > https://lists.torproject.org/pipermail/tor-dev/2013-November/005878.html > related to the HSDir hashring in rend-spec-ng.txt. > > And check out the "Trawling Hidden Services" paper by Ralf et al. > > For example, on a more key management tone, petname systems for HSes > would be very interesting, which is related to the recent work of > GNUNet with GNS: > https://gnunet.org/gns > > BTW, keep in mind that some of these projects will be moving during > the next year. > > Also, if you have public questions which would benefit more people, it > would be great if you could post in [tor-dev] instead of here. It's > good to answer obscure HS questions in public so that more people can > understand the protocol. > > Ah, I'm also a fan of the FluxFingers team :) > > Thanks for the interest and hope this was useful.

7 9

Release: obfs4proxy-0.0.4
by Yawning Angel 17 Feb '15

17 Feb '15

Hello all, I just tagged obfs4proxy-0.0.4, though the changes do not affect most people directly, I figured it's worth an announcement. Changes in version 0.0.4 - 2015-02-17 - Improve the runtime performance of the obfs4 handshake tests. - Changed the go.crypto import path to the new location (golang.org/x/crypto) - Added client only support for ScrambleSuit. This is more useful for the Tor Browser people than anyone else since it means that the next build can remove the old go.crypto cruft from the build process, and the ScrambleSuit client provider can be switched over to obfs4proxy like obfs2 and obfs3 have been. With Go PTs being phased into Orbot as well, this release should allow for a smooth transition from obfsclient to obfs4proxy. A note about the build time dependency change, for packagers: What: code.google.com/p/go.crypto -> golang.org/x/crypto Why: The Go developers decided to move the repository, and Go libraries are referred to in the code via import location. The source in the code.google.com repo was also updated to mirror the new repository, so internal dependencies all reference the new location. Workarounds: If changing the build time dependency is not an option, you have an existing go.crypto package that will not change, and you are building with Go < 1.4, revert: cdeda5724124ca393c87be6d01c84fe4f906d612 Old copies of go.crypto will not compile with newer versions of the Go compiler so packaging golang.org/x/crypto is advised in the medium to long term. Questions, comments, feedback appreciated, -- Yawning Angel

1 0