Direct onion services over Tor

Although it is best known for safeguarding the anonymity of Internet users on the client side, the Tor project has long supported hidden services as well. A hidden service is a mechanism that lets administrators run an Internet server entirely within the Tor network—thus protecting the server owner's anonymity as well as the client's. Now the project is exploring another service option that would be tailored to a different use case. Direct Onion Services, as the idea is currently (and, indications are, temporarily) known, would offer the client-side user the privacy-protecting features already available with hidden services, but with reduced overhead on the server side. The scheme would mean that the server gives up its anonymity, but in doing so it gains improved speed and ease-of-use.

Traditionally, Tor hidden services provide anonymization to both the client and the server during a session. The client must connect over the Tor network, and the server is listening only on a virtual interface that is also connected to Tor (and which is reachable only through a .onion domain name). Originally, the reason for this design was that the server could remain just as anonymous as the client user. No one could determine the owner of an anonymous dissident's blog by tracing the traffic of a Tor hidden service, since that traffic is routed through multiple relays.

The trouble with anonymous .onion services

But experience has shown that there is a downside to hidden services. Configuration is hardly trivial (although the project is doing what it can to simplify the process) and, more importantly, routing the hidden service's traffic through multiple relays—three hops, by default—means increased latency and reduced bandwidth. And, as it turns out, there are quite a few hidden-service providers that care little about their own anonymity, and run their service over Tor primarily for the benefit of their users—allowing those users to access the service over a secure, anonymous connection free from prying eyes.

The main example of this scenario is a public Internet service that maintains a separate Tor entry point as an end-user convenience, such as the Facebook hidden service at https://facebookcorewwwi.onion/. The fact that the server belongs to Facebook is not secret in the least; the .onion site is there to give users an encrypted and authenticated (due to .onion URLs self-authenticating design) way to access the site when using a network that might block or intercept a normal web connection. For sites like Facebook, the multi-hop routing of traffic adds network overhead, but no anonymity.

Consequently, the Tor project has been exploring ways to offer a better solution for "public" .onion services. George Kadianakis raised the question in a March 30 blog post that solicited ideas from the public about how hidden services could be improved. On April 9, Kadianakis sent a proposal to the Tor development list outlining what he called "direct onion services."

The proposal highlights the aforementioned well-known-public-site use case, but it offers a few other possibilities as well. Wikileaks, for example, uses a .onion service for whistleblowers to submit information, despite (like Facebook) not attempting to anonymize itself in the process. Rather, Wikileaks's use case is that the .onion entry point is a "succeed or fail hard" proposition—meaning that users can either connect to the service and know that their Tor-based connection is authentic and encrypted, or they cannot connect at all. It is impossible for a user to unknowingly connect to the upload site by insecure means.

Another example is applications that lack authentication or encryption at the protocol level. The proposal cites a plan by Freenode to offer IRC access over an .onion service, which would grant users security and anonymity that the IRC protocol itself lacks.

Public .onion services

The essence of the proposal itself is straightforward. Normally, a hidden .onion service establishes two types of entry-point connections on Tor. The first are introduction points: randomly chosen Tor nodes to which the service distributes its public key at start-up time. That key is then added to Tor's distributed hash table (DHT) from multiple sources to further evade tracing the server's location; users wanting to reach the service grab the key from the DHT, hash it, and the hash serves as hostname component of the service's .onion URL. The second variety of entry point type is the rendezvous point—a randomly chosen Tor node that the client selects to connect to the service. The client and the service each create their own circuit to the rendezvous point, rather than connecting directly.

The proposal states that a non-anonymous service needs a way to establish one-hop Tor circuits for both types of entry points, and that it must not connect to guard nodes (a special class of Tor entry node). Ideally, there will be a way for users to enable these configuration parameters in a simple manner, such as by setting a specific option in the .torrc configuration file.

In the original hidden-service design, each circuit between the server and an entry point can be multiple hops long. Reducing those excess hops decreases round-trip time and, in the case of high-traffic services, it also reduces the amount of overall network traffic sent over Tor.

The guard-node issue is slightly different. Nodes are assigned the "guard" flag by Tor's bandwidth-monitoring servers; a guard is a high-bandwidth node that is designated as a good entry point to the Tor network for clients. When other Tor nodes see that a node has been designated a guard, they reduce the number of intermediary connections they establish through it. Thus, a high-traffic .onion service could have an undue crippling effect on multiple Tor users if it sends its higher-than-average traffic through a guard.

Kadianakis based the proposal on an earlier, unimplemented idea from Roger Dingledine. Dingledine's idea did not address guard nodes, and it posited doing away with rendezvous points, but the end goal remains essentially the same.

Kadianakis also asked whether or not the project should provide special Tor builds tailored for public .onion services (since it already provides special builds for Tor-to-web gateways). David Goulet replied that this would likely not be useful, since it would limit the ability of service operators to choose between .onion service types on the fly.

Jacob Haven addressed a more fundamental issue, noting that, if the public .onion service operator was not concerned about their own anonymity, the introduction points and rendezvous points themselves may be unnecessary. The service could advertise itself in some simpler manner and users could connect to it directly, thus reducing Tor network load even further.

Kadianakis replied that such simplifications would indeed be likely to provide additional speed improvements, but that they would require changes to the hidden-service codebase. There is also a downside, he added, in that the rendezvous-point connection protocol is able to punch through NAT, while listening for direct connection requests would potentially be blocked by NAT.

On the whole, though, there appears to be rough consensus that the idea is well worth pursuing, and there has indeed been some preliminary development work by Alec Muffett. Amusingly enough, the big unresolved question at this point appears to be what to call the new feature. Kadianakis cautioned in his original email that the name "direct onion service" would likely need revisiting—it is not particularly descriptive, and the acronym DOS has an unfortunate name collision with "denial of service." So, too, does his follow-up suggestion "dangerous direct onion service" as well as several of the ideas proposed in the discussion thread (such as Matt "Speak Freely"'s suggestion "peeled onion service").

Then again, the name Tor itself has never been especially new-user-friendly either. In reality, what matters most is that Tor can provide the anonymity and privacy safeguards that its users—client or server—depend on. This proposal looks to be further meeting the needs of users in both categories.