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-ou... 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-c... 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.tx... 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... 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-discov... 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-balanci... 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.tx... 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!
========================================================================