Hi,
those of us who don't follow tor-dev closely may be interested in this
nice summary of the hidden^Wonion services improvements that are in
the works.
[Jurre: you'll understand why I'm forwarding this and Cc'ing you.]
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@???
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
--
intrigeri
