tor-dev

tor-dev@lists.torproject.org

October 2015

64 participants
82 discussions

Expanding services: Single-onion and OnioNS
by Hugo Maxwell Connery 01 Oct '15

01 Oct '15

Hi, Having reviewed the last couple of months of tor-dev mails, i can see that there are many proposals afoot to expand the uptake of tor hosted services. These range from a new service type, single-onion [0], to load balancing of tor hosted services [1], to hosting new name/value pairs (x-namespace) [2], to new name services (OnioNS [3] and better integration of Gnu NS [4]), to name a few that caught my eye. The fact that Facebook (which I wholely dislike) expended considerable effort in generating a human readable location hidden service address and then strongly participated in IETF discussions to declare .onion as a special case TLD reservation indicates that the perception of the validity and significance of the tor network is growing. I have comment on single-onion services and on name services. For single onion services, in which client -> guard -> middle -> middle -> single-onion, the role of the second middle relay changes. In the traditional sense it merely knows that it is part of a circuit connecting two relays, and has no knowledge at all about either source (client) or destination (normal web service). For single onion services the second middle relay can know something about the service to which it is connecting. As Yawning Angel points out [5] this may provide censorship opportunities. For this, I suspect that single onion service operators need to be made aware of this risk. If they are aware, they can persue strategies to mitigate (e.g run multiple contact points over a back end). John Brooks identifies [6] a potential risk for the second middle relay operator if the single onion service is malicious (keeps detailed logs, runs a honeypot etc.). For this case, and to help peole who provide large capacity middle relays (e.g Mozilla) and wish for no legal risk, a config flag may need to be provided which allows middle relays to choose not to connect to single onion services. There may be other, better strategies. I wish also to highlight the potential importance of Jesse V's OnioNS [7]. I am highly supportive of alternatives to the DNS, which despite efforts ongoing in the IETF, will never be secure against surveillance. OnioNS attempts to solve Zooko's triangle. It seems a well considered name system, and I encourage others to examine it. The key benefits are that a service can choose a name for itself, but must do work to do so, and must regularly do work to maintain the name (thus costing squatters effort). The name service operates entirely within the location hidden services space and thus offers the protections inherent in that. Registration is at the second level (e.g example.tor) but can also at the same time register lower levels names (e.g xmpp.example.tor and gopher.example.tor). Regards, Hugo [0] https://lists.torproject.org/pipermail/tor-dev/2015-September/009408.html [1] https://lists.torproject.org/pipermail/tor-dev/2015-September/009597.html [2] https://lists.torproject.org/pipermail/tor-dev/2015-September/009588.html [3] https://lists.torproject.org/pipermail/tor-dev/2015-September/009585.html [4] https://lists.torproject.org/pipermail/tor-dev/2015-September/009560.html [5] https://lists.torproject.org/pipermail/tor-dev/2015-September/009416.html [6] https://lists.torproject.org/pipermail/tor-dev/2015-September/009415.html [7] https://github.com/Jesse-V/OnioNS-literature/raw/master/conference/conferen…

1 0

Re: [tor-dev] Second release of OnioNS beta
by Jesse V 01 Oct '15

01 Oct '15

Heads-up everyone, After some debugging with s7r, it appears that sometimes the programs (onions-server, onions-hs, or onions-client) fail to start because they cannot load the common library. So if you run any of the programs in the terminal, you will see an error that libonions-common.so cannot be found, or they simply won't run if you start them without an active terminal. This is because that library is installed to /usr/lib/onions-common, but the loader is looking for it in /usr/lib/, among other locations. I do set the RPATH in CMake in an attempt to fix this, but in some cases (at least in my build for Debian Wheezy) it may not be set or installed correctly. I'm investigating and looking through https://cmake.org/Wiki/CMake_RPATH_handling If this occurs, there are two workarounds. The first is to run export LD_LIBRARY_PATH="/usr/lib/onions-common" before running any of the software. The second is to add "/usr/lib/onions-common/" (without quotes) to /etc/ld.so.conf Both should tell the loader to look for the library in the correct path. This issue might also occur on Fedora under the for the experimental .rpm, but I'm not sure. The issue doesn't occur on my computer, but if it also applies to Ubuntu or Mint, please let me know. It's always possible to compile from source and run the software from the build directory, but I would really like to identify the scope of this issue and then properly fix it. Thanks, Jesse V.

1 1