Future Development on Hidden Services

Sun Nov 2 16:33:17 PST 2008

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi list,

as some of you may know, there have been several improvements to hidden
services lately. First, hidden services publish their descriptors to a
distributed directory [1] consisting of currently 71 nodes. Second,
hidden services may require client authorization already during
connection establishment to block unauthorized requests as early as
possible [2]. Third, hidden service performance has been improved with
respect to advertising and accessing hidden services [3,4].

Certainly, there are still things that can (and should) be improved.
This is an attempt to compile a good list of future development tasks on
hidden services. Comments are most welcome. If there are other things
with hidden services that need improvement, please let us know.

- --Karsten

1.  Further improve performance and reliability
- ----------------------------------------------

In the current NLnet project on speeding up hidden services [3] we found
and fixed a lot of performance-related bugs, identified the likely
bottlenecks of the protocol, and added the most important performance
improvements to the code [4]. But there are still some possible
improvements left that require evaluation and possibly coding if they
turn out to be useful:

a.  Descriptor fetches on client side are an issue. Most failed
connection establishment occur when trying to fetch the descriptor of a
hidden service. We could parallelize this step as well (maybe also in
combination with a certain delay to avoid extensive network load), just
as we do with client-side requests to introduction points [4]. This
might speed things up and lead to better reliability (at the price of
increasing the number of requests to the distributed directory).

b.  The client-side request timeout of 60 seconds could be improved. It
doesn't make sense to have a 60-seconds timeout for 5 substeps and stick
to it even when realizing that the first substep has already taken 55
seconds. The other 4 steps (that are invisible to the client) simply
cannot succeed in that time. This would also improve reliability,
because we are otherwise giving up on requests that succeed soon after.

c.  The INTRODUCE1 cells could be combined with the first BEGIN cell to
initialize an application stream. After establishing a 6-hop circuit
from client to service, the client still needs to initialize an
application stream over it which takes another 6 seconds in the mean.
Maybe there is a chance to send the stream initialization message
already as part of the introduction request. Or the hidden service could
initialize the first stream back to the client. There might be security
implications that prevent this, so more thoughts are needed here.

d.  Adapt the protocol to low-bandwidth environments: The effects of
low-bandwidth connections on either accessing or running hidden services
has not been investigated so far. Maybe such environments require us to
change parameters like timeouts when we realize that our connection is
bad. Jvrg Lenhard is currently working on measurements using telephone
and cell phone connections that hopefully give us some new insights.

e.  One of the big performance issues is general Tor circuit-building
performance. This comes in two pieces: First, extending a circuit in Tor
has a nontrivial chance of timing out or failing. Second, extending a
circuit in Tor takes too long, both in terms of mean and in terms of
variance. These problems are magnified for hidden service use, a)
because the path is twice as long, and b) because some components of the
path really do need to be made on demand, whereas for normal Tor
circuits you make the whole circuit beforehand. So, if this improves for
general circuits in Tor, hidden services should inherit these
performance gains 'for free'.

2. Improve hidden services with client authorization
- ----------------------------------------------------

Beginning with version 0.2.1.6-alpha, hidden services support client
authorization. That means that hidden services can restrict access to a
small set of clients and prevent other clients (or introduction
points/directory nodes) from establishing a connection. When client
authorization is applicable, it reduces the risk of certain attacks on
locating hidden servers [6] or denial of service. Once this feature is
more tested, people should be told that it exists and how to use it.

a.  Make client authorization for hidden services easier to use: Domenik
Bork has made a start on making Vidalia support configuration of hidden
services with client authorization in his GSoC project [7]. His changes
will hopefully be merged into Vidalia trunk quite soon. The question is
whether people understand the interface, or if this needs improvement.

b.  Write good howtos for both service operators and clients: First,
explain to the service operator what steps are required to add or remove
authorization for a given client. Second, help end users understand how
to configure their clients, what protection they get, and a brief idea
of how it all works; we may reuse some parts from the current
documentation and FAQ, but the client authorization features are rather
new and not documented.

c.  Work on advanced client authorization protocols: The two available
protocols for client authorization are based on exchanging a secret
between service provider and client. This could be extended to other
protocol types as required. The question is what users need.

3. Simplify setting up a hidden service
- ---------------------------------------

One option to make it easier for people to run hidden services is to
make a Tor Webserver Bundle: Given the success of the Tor Browser
Bundle, we could create a Windows/Mac OS bundle that contains Tor,
Vidalia, and a tiny webserver. The bundle could have a directory
"put-your-files-here/" where people can drop HTML (or other) files that
are served by the hidden service automatically. The bundle could live on
a USB stick without the need to be installed. This bundle could be
developed as an extension of the current TBB. Maybe this could also go
into the new auto updater [5] as an optional package.

[1]
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/114-distributed-storage.txt

[2]
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt

[3] https://www.torproject.org/projects/hidserv

[4]
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/155-four-hidden-service-improvements.txt

[5] https://www.torproject.org/projects/google

[6] http://www.freehaven.net/anonbib/#hs-attack06

[7] http://code.google.com/soc/2008/eff/appinfo.html?csaid=86500DD2D78BB5D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJDkbN0M+WPffBEmURAswDAKCVzkN/mr+5IpT/F4eRzGWK2d4HiwCgqZiB
2fpktR6KApl+bziOXIv0q08=
=BbIk
-----END PGP SIGNATURE-----

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE