- tor-dev - lists.torproject.org

Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are blocked by China's firewall.
by Li Xiaodong 01 Oct '15

01 Oct '15

*Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are blocked by China's firewall. When will SkypeMorph Pluggable Transports and Dust Pluggable Transports be deployed in Tor Browser? There are no directory servers in I2P network. Can Tor learn from I2P? If Tor user have to access directory servers by bridges, I feel that Tor will be easily blocked by China's firewall. Can Tor no longer use directory servers in future? Since 2010 China's firewall has blocked all of the IP addresses of Tor directory servers. Thank you very much for your help. I really appreciate it. All the best with your work. Good luck in all that you will achieve.*

3 2

Hello, thank you very much for your help. I really appreciate it.
by Li Xiaodong 01 Oct '15

01 Oct '15

*Hello, thank you very much for your help. I really appreciate it. In this afternoon of China Time, I found a obfs4 bridge which is usable in China. The speed of Tor Browser connecting with obfs4 bridge, and the speed of Tor Browser connecting with Meek Azure, which is faster? It is more difficult for China's firewall to block I2P. If Tor can learn some strong points of I2P in future, Tor can work better in China. Thank you very much for your help. I really appreciate it. All the best with your work. Good luck in all that you will achieve.*

2 1

Hello, thank you very much for your help. I really appreciate it.
by Li Xiaodong 01 Oct '15

01 Oct '15

*Hello, thank you very much for your help. I really appreciate it. I don't know how long I can use the obfs4 bridge which I found. Maybe after two weeks the obfs4 bridge which I found would be blocked by China's firewall.*

1 0

Re: [tor-dev] Onion Services and NAT Punching
by Nathan Freitas 01 Oct '15

01 Oct '15

On Thu, Oct 1, 2015, at 01:15 AM, Andreas Krey wrote: > On Wed, 30 Sep 2015 17:12:53 +0000, Tim Wilson-Brown - teor wrote: > ... > > Are there any use cases that: > > * need NAT punching, > > * don???t need service location anonymity, and > > * would benefit from lower latency? > > Of course. All the cases where you set up a hidden service > exactly because your host is behing a NAT. > > Like the webcam raspi I'm just booting up. I have been looking at the use of Tor and Onion Services for Internet of (Onion'd) Things applications, but broadly I haven't thought how and when single onions could add extra benefit. Mostly in IoOT (IoO?) the goal is to remove the centralized corporate clouds that are currently used, and to protect your endpoints (house, car, office, etc) from becoming easily discovered and compromised. Accessing a home webcam ("dropcam" or "baby monitor" in the common parlance) is the best example I can think of where you want all the Tor goodness, and lower latency is also needed. Most of the other apps I can think of can deal with async messaging and high latency (i.e. change/check your thermostat settings). +n

1 0

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

Draft proposal -- no number yet: How to safely drop support for old clients.
by Nick Mathewson 30 Sep '15

30 Sep '15

[This isn't done yet, but I've shown it to enough people that I should share it with the list.] 1. Introduction and background 1.1. Motivation Frequently, we find that very old versions of Tor should no longer be supported on the network. To remove relays is easy enough: we simply update the directory authorities to stop listing them. But to disable clients is harder. We can do as we did with v1 directories in Tor 0.2.0.5-alpha, and make them know about no relays at all. Stepping back -- why should we disable very old clients at all? Here are some reasons why: * Security. Anybody who hasn't updated their Tor client in 5 years is probably vulnerable to who-knows-what attacks. They aren't likely to get anonymity either. * Withstand zombie installations. Some Tors out there were once configured to start-on-boot on now-unmaintained systems. They put needless load on the network, and can't be easily disposed of. * Disable backward-compatibility code. Currently, Tor supports some truly ancient protocols in order to avoid breaking ancient versions. If we disable these protocols without turning off the clients that use them, we run the risk that those clients will run wild, retrying their connections to the network over and over. This document describes a designs for use with future versions of Tor to better support client deprecation and removal. It also describes how we can safely disable existing client versions that do not support this proposal. 1.2. History Early versions of Tor checked the recommended-versions field in the directory to see whether they should keep running. If they didn't recognize 1.3. Goals and requirements We need older clients to stop putting (much) load on the network. Having them stop working entirely is not sufficient: they need to stop working in such a way that they don't keep using up resources. In the future, when we disable a client, it would be a good thing to provide some means to warn users in advance that they need to upgrade, and to provide advice about doing so. It might be good to make any disable-switches advisory rather than mandatory. 2. Adding a disable-clients switch to consensus documents I specify a new consensus element: disable-versions. It may appear any number of times in a consensus document. The syntax is: disable-versions SP SOFTWARE SP ROLE SP DATE SP VERSIONS DATE = A date in YYYY-MM-DD format ROLE = "relay", or "all". SOFTWARE = "Tor" VERSIONS = VERSION_RANGE VERSIONS = VERSIONS SP VERSION_RANGE VERSION_RANGE = VERSION VERSION_RANGE = VERSION..VERSION [TODO: Specify voting.] If the current version is listed in any disabled-versions line for its current role, then we should warn the user. If the current date is on after the date specified (starting midnight UTC), we should disable the host as follows: * If 'relay' is the disabled role, then we should enter ClientOnly mode. * If 'all' is the disabled role, we should enter DisableNetwork mode. Note that the DisableNetwork behavior means that once a client is disabled, it will not fetch new consensuses. To override this, a Tor instance may include a configuration option, "IgnoreDisabledVersion VERSION". It is an error to set this option when *not* running with a disabled version. [ALTERNATIVE: Make RequireLinkProtocol, RequireCircuitProtocol, etc lines for the consensus. Any Tor not supporting those protocols should behave as above. This allows non-Tor implementations to respect these fields.] 3. Disabling current client versions. 3.1. Disabling versions that use the v2 handshake These versions (before 0.2.3.6-alpha) use a renegotiation-based handshake instead of our current handshake. When we detect a renegotiation attempt, we can close the connection, or stop reading on it. 3.2. Disabling versions prior to 0.2.4.11-alpha. Starting in version Tor 0.2.4.11-alpha, we implemented proposal 214. This proposal added a new link protocol, version 4. Earlier version of Tor never support it; newer versions of Tor always advertise their support for it. We could treat the presence of any link protocol of version 4 or later as indicating the presence of 0.2.4.11-alpha. Upon receiving a connection from such a version, we could throttle the bytes we give it, drop its circuits, or stop reading. [TODO: which?] 3.3. Disabling versions prior to 0.2.5.x In tor 0.2.5.1-alpha, we began ignoring the UseNTorHandshake option, and always preferring the ntor handshake where available. Unfortunately, we can't simply drop all TAP handshakes, since clients and relays can still use them in the hidden service protocol. But we could detect these versions by: Looking for use of a TAP handshake from an IP not associated with with any known relay, or on a connection where the client did not authenticate. (This could be from a bridge, but clients don't build circuits that go to an IntroPoint or RendPoint directly after a bridge.) In response, we can throttle the connection, drop all its circuits, or stop reading on it. [TODO: which?] 3.4. Disabling all versions that don't support this proposal We should allow 'n' (short for "node") as a synonym for 'r' in consensus documents. Later, if we want to disable all Tor versions before today, we can change the consensus algorithm so that the consensus (or perhaps only the microdesc consensus) is spelled with 'n' lines instead of 'r' lines. This will create a consensus which older clients and relays parse as having no nodes. 3.5. In the event of overzealous retries We need to be sure that client running versions from 0.2.1 through 0.2.6 respond gracefully to the responses above. In particular, we need to make sure that they don't continually retry the connections that fail in these ways: that would put a lot of extra load on the network. Above, I recommend stalling connections rather than just closing them. This may prevent the risk of retries, at the risk of using additional relay resources. To handle something like this, it could be necessary to use the trick of 3.4 above.

4 3

Anycast Exits (related : Special-use-TLD support)
by Jeff Burdges 30 Sep '15

30 Sep '15

I have attached below the second half of the Special-Use TLD proposal that discusses how a local name service tool contact a peer-to-peer application running on an exist node There is nothing specific here to providing name services, any peer-to -peer application might potentially want an anycast style gateway from Tor to its own network. At the same time, this proposal is *very* hackish since Tor seems almost able to provide the same functionality with a judiciously chosen ExitPolicy lines, and a bunch of work on the application's side. And maybe that's really the right way to do it in the end. There is no discussion here of dealing with bad exit gateways for protocols that Tor does not even know about, presumably that requires some thought as well. I donno if Tor combats exits doing highly targeted DNS manipulation all that well either though. Jeff Filename: xxx-anycast-exit.txt Title: Anycast Exit Author: Jeffrey Burdges Created: 28 September 2015 Status: ? Implemented-In: ? Abstract Provide an anycast operation to help bootstrap Tor aware peer-to-peer applications. Overview Peer-to-peer protocols must define a method by which new peers locate the existing swarm, but available techniques remain rather messy. We propose that Tor provide an "anycast" facility by which peer-to -peer applications built on top of Tor can easily find their peers using the full aka useless descriptors. Server Side We propose an AnycastExit Tor configuration option AnycastExit <protocol> <host>:<port> Here protocol must be a string consisting of letters, numbers, and underscores. There are two changes Tor's behavior resulting from this option : First, Tor adds the line "ACE <protocol> <host>:<port>" to the node's full descriptor. Second, Tor allows connections to ip:port as if the torrc contains : ExitPolicy allow<host>:<port> As ExitPolicyRejectPrivate defaults to 1, these policies should be allowed even if the ip lies in a range usually restricted. In particular localhost and 127.0.0.1 are potentially allowed. Client Side Users enable anycast usage by adding the configuration line FetchUselessDescriptors 1 Software queries the Anycast lines in the full descriptor by sending Tor control port the line : GETINFO anycast/<protocol>/<number> This query returns 250-anycast/<protocol>/<number>="<host>.<identity>.exit:<port>" where <identity> is a node identity for a node whose full descriptor contains the line "Anycast <protocol> <host>:<port>". After receiving such a query for anycast nodes supporting <protocol>, Tor builds, and later maintains, a list of nodes whose full descriptor contains an "ACE <protocol> .." line in lexicographic order according to <identity>. Tor returns the <number>th node from this list. Also, if <number> exceeds the number of nodes with Anycast <protocol> lines, then an error is returned. Clients contact the anycast server <host>.<identity>.exit on port <port>. As AllowDotExit defaults to off, applications should use the Tor control port to request a circuit to that particular exit using MapAddress: MapAddress <host>.<identity>.exit=<label> After this, the peer-to-peer application can connect to <label> over the Tor socks port. MapAddress usually produces a four hop circuit, but many peer-to-peer applications, including name service provides, can accept the small additional latency. Future Work Tor directory authorities could aggregate the lists of anycast supporting nodes, so that clients do not need to download the full descriptors. AnycastExit could support UNIX domain sockets. Hackish Alternative In principle, the ExitPolicy line produced by AnycastExit might suffice if both doing so bypasses ExitPolicyRejectPrivate, and the port could identify the protocol. Additionally, an application could parse the cached-descriptors* files themselves to locate exits with the desired exit policies. Acknowledgments Based on discussions with George Kadianakis, Christian Grothoff. Indirectly based on discussions between Christian Grothoff and Jacob Appelbaum about accessing the GNU Name System over Tor.

2 2

Rate limiting of a hidden service
by Evan d'Entremont 30 Sep '15

30 Sep '15

I developed a scheme to rate limit hidden services using proof-of-work; https://gist.github.com/evandentremont/a3ad12a5cc3a924dae34 The server sends a semi-prime to the client, which then factors it. The client submits the factored primes back with the next request. The 'rate' can be throttled by sending a larger or smaller semiprime. The client has to spend time factoring that number, and the request can simply be dropped if the factored primes aren't correct. It would be effective to hinder brute force attacks on a login screen at the very least. Running as a script on the page isn't ideal as a lot of people disable javascript. There's always the option for a fallback where you calculate the primes yourself and submit them, but I feel like it would be better implemented as part of tor itself. Just throwing this out there for thoughts / feedback / opinions on rate-limiting hidden services.

1 0

Approaching Deadline: ICGCTI2015 - Malaysia
by Jackie Blanco 30 Sep '15

30 Sep '15

The Third International Conference on Green Computing, Technology and Innovation (ICGCTI2015) Universiti Putra Malaysia, Selangor, Malaysia 8-10 December 2015 http://sdiwc.net/conferences/icgcti2015/ The proposed conference on the above theme will held over three days, with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. ICGCTI2015 aims to enable researchers build connections between different digital applications. The conference welcomes papers on the following (but not limited to) research topics: - Benefits of, and barriers to, adopting greener IT practices - Carbon metering and user feedback - Climate and ecosystem monitoring - Energy harvesting, storage, and recycling - Energy-aware high performance computing and applications - Energy-aware software - Energy-efficient network services and operations - Green IT metrics, maturity models, standards, and regulations - Green computing models, methodologies and paradigms - Green networking and communication - Life-cycle analysis of IT equipment - Management and profiling tools for energy efficient systems - Modeling-representations, simulation and validation for energy consumption optimization problems - Online dynamic optimization for energy efficient systems - Power-aware algorithms and protocols - Power-efficient delivery and cooling - Renewable energy models and prediction - Smart buildings and urban development - Smart homes, buildings, offices, streets - Stability of smart energy systems - Using IT to reduce carbon emissions - Carbon management policies and ecology- related issues with ICT - Characterization, metrics, and modeling - Creating green awareness using IT - Energy-aware computing - Energy-aware large scale distributed systems, such as Grids, Clouds and service computing - Energy-efficient mass data storage and processing - Governments’ roles in fostering and enforcing green initiatives - Green business process reengineering and management - Green design, manufacture, use, disposal, and recycling of computers and communication systems - Green software engineering - Low-power electronics and systems - Matching energy supply and demand - Network design optimization - Optimization of energy-efficient protocols - Power-aware software and hardware - Reliability, thermal behavior and control - Robustness and performance guarantees - Smart grid and microgrids - Smart transportation and manufacturing - Sustainable computing Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Important Dates ============== Submission Deadline : November 8, 2015 Final Notification : November 20, 2015 Camera Ready Deadline : November 28, 2015 Registration Deadline : November 28, 2015 Conference Dates : December 8-10, 2015 Drop us an email at icgcti15(a)sdiwc.net

1 0