[tor-dev] Status of Open Hidden Service Proposals (October 2015)

[George Kadianakis <desnacked@xxxxxxxxxx>]

Greetings,

it's well known that hidden services need some love:
 https://blog.torproject.org/blog/hidden-services-need-some-love

For the past 2 years we've been busy designing the upcoming hidden service
protocol with improved cryptography, security, and performance. During this time
we've written a good amount of improvement proposals and specifications, that
have now been floating around our git repositories. In this mail I aim to
collect and briefly explain all these proposals in one place so that researchers
and developers have easier access to them. Ideally we would also make a wiki
page tracking them.

Similar efforts have been done for the set of all Tor proposals by Nick:
 https://blog.torproject.org/blog/tor-design-proposals-how-we-make-changes-our-protocol
 https://gitweb.torproject.org/torspec.git/tree/proposals/proposal-status.txt

This might also make for an informative blog post if I clean it up a bit. Please
let me know if I should try to get it posted on the blog so that it reaches a
greater audience.

Let's start walking over each proposal in a hopefully reasonable order:

========================================================================

== Proposal 250: Random Number Generation During Tor Voting ==

   [Prerequisite proposal]

   URL: https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-consensus.txt
   Status: [Under development - https://trac.torproject.org/projects/tor/ticket/16943]

   This is a prerequisite for the proposals that follow. It specifies how the Tor
   directory authorities can produce a fresh and unpredictable random value
   every day.

   We plan to use this value to randomize the responsible HSDirs of hidden
   services and make them unpredictable. This will help defend against attacks that
   require the attacker to become the HSDir of a hidden service.
   
== Proposal 224: Next-Generation Hidden Services in Tor ==

   [Main proposal!]

   URL: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt
   Status: [Under development - https://trac.torproject.org/projects/tor/ticket/12424]

   This is the master proposal of the "Next Generation Hidden Services" project.

   It outlines a more or less completely revised version of the Tor hidden
   services protocol, improved to accomodate better cryptography and defenses
   for several attacks we'd never considered when we did the original design!

   The following proposals plug into the protocol specified by this proposal.

== Proposal 246: Merging Hidden Service Directories and Introduction Points ==

   [Performance improvement]

   URL: https://gitweb.torproject.org/torspec.git/tree/proposals/246-merge-hsdir-and-intro.txt
   Status: [Research Phase - https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html]

   This document describes a modification to proposal 224, which simplifies and
   improves the architecture by combining hidden service directories and
   introduction points at the same relays. It will speed up the initial
   connection to hidden services considerably since only two circuit
   establishments will be needed instead of three.

== Proposal 247: Defending Against Guard Discovery Attacks using Vanguards ==

   [Security improvement]

   URL: https://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-discovery.txt
   Status: [Research Phase - https://lists.torproject.org/pipermail/tor-dev/2015-July/009066.html]

   This document describes a modification to the path selection for hidden
   service circuits. It aims to defend against attacks where clients try to discover the
   hidden service's guard relay(s).

   This proposal also depends on having better and more robust algorithms for
   guard node selection. This requires another mini-proposal:
    https://lists.torproject.org/pipermail/tor-dev/2015-August/009297.html

== Proposal 255: Controller features to allow for load-balancing hidden services ==

   [Scalability improvement]

   URL: https://gitweb.torproject.org/torspec.git/tree/proposals/255-hs-load-balancing.txt
   Discussion thread: https://lists.torproject.org/pipermail/tor-dev/2015-September/009597.html
   Status: [Under Development - https://trac.torproject.org/projects/tor/ticket/17254]

   We have plans for bringing hidden services to the next level. We are talking
   hidden services with 100x the clients they can currently handle, and with
   mechanisms that allow operators to load balance and achieve high availability.

   This proposal defines a way for hidden services to _load balance_ their
   clients by allowing *multiple hosts* to do the actual rendezvous with the
   clients. This is something that busy hidden service operators need
   currently.

   On the scaling front, we also worked on onionbalance which allows operators
   to have _high availability_ by allowing multiple hosts that handle
   introductions. Onionbalance is already usable by operators, and we have
   various improvements that we want to do in the future:
    https://github.com/DonnchaC/onionbalance
   
== Proposal 252: Single Onion Services ==

   [Optional Performance improvement]

   URL: https://gitweb.torproject.org/torspec.git/tree/proposals/252-single-onion.txt
   Status: [Research Phase - https://lists.torproject.org/pipermail/tor-dev/2015-September/009408.html]

   Websites like blockchain.info and Facebook are starting to offer hidden
   services to their clients. They do so to protect their clients from the
   fundamental exit-node attacks and also to provide them with Tor-specific
   features. Using hidden services in this context is also good news for the
   whole Tor, since hidden service circuits don't require exit relays who are
   the current bottleneck of the network.

   However, services like blockchain.info don't care about their anonymity; they
   only care about the anonymity of their clients. For services with this threat
   model, there are protocol modification that we can do to provide greater
   performance and load balancing options, since they don't need the 3-hop
   anonymizing circuits of Tor. Proposal 252 specifies how we can modify the Tor
   protocol to better accomodate services with this use case.

   Of course this would be an *opt-in setting* only for the services that want it.

== Proposal: Direct Onion Services ==

   [Optional Performance Improvement]

   URL: https://lists.torproject.org/pipermail/tor-dev/2015-April/008625.html
   Status: [Under Development - https://trac.torproject.org/projects/tor/ticket/17178]

   Proposal 252 "Single Onion Services" requires some protocol modifications
   that render it backwards _incompatible_. This means that Tor clients need to
   be updated to use these "single onion services".

   In the meanwhile services with the blockchain.info threat model that want to
   enjoy greater performance even with the current protocol can simply use 1-hop
   circuits for their server-side circuits. This should grant better performance
   with no cost to client anonymity while remaining backwards compatible.

   The "Direct Onion Services" proposal specifies how this should be done. I
   hear a newer version of the proposal will soon come out!

========================================================================

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev