-----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-... [2] https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/121-hidden-servi... [3] https://www.torproject.org/projects/hidserv [4] https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/155-four-hidden-... [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