[tor-dev] Improving Tor Hidden Services

Tue Mar 27 09:08:36 UTC 2012

On 2012-03-23, Arturo Filastò <art at baculo.org> wrote:
> Setting aside the issue related with usability there are also some
> interesting
> improvements that can be made to make Tor HS more performant.
>
> I will summarize here the ideas that have been brought forward along
> with some
> that are not detailed anywhere and would like to see more interest in.
>
> I would suggest to start collecting all the information regarded to Tor HS
> improvements on this wiki page:
> https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/HiddenServices.

I would suggest not using the Tor wiki for anything important, and in
particular, I would suggest not using the Tor wiki for anything that
you plan to try to blame me for.  The Tor wiki is nearly unusable, and
it has become a menace to Tor users' safety, and I want it shut down.
I'm never going to use it for anything important.

> With respect to what is already on that page I got some feedback from
> rransom
> on those two items on IRC, but I did not note them down. It would be
> good if you
> were to summarize the critiques here or on the wiki page.

Please send the text to tor-dev.  I'm not going to comment here on
documents which are so easily editable.

> Also there are a set of proposals that are related to Tor HS
> improvements that
> have been abandoned for some time and I believe it would be useful to
> summarize
> them inside of that wiki page.
>
> The proposals are:
>
> #121
> Filename: 121-hidden-service-authentication.txt
> Title: Hidden Service Authentication
> https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/121-hidden-service-authentication.txt

This was implemented in Tor.

> #142
> Filename: 142-combine-intro-and-rend-points.txt
> Title: Combine Introduction and Rendezvous Points
> https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/142-combine-intro-and-rend-points.txt

This was rejected, mainly because it would make certain relays appear
to be ‘responsible for’ a particular hidden service.  Also, I would
expect it to overload relays' bandwidth.  This one should not be
implemented.

> #143
> Filename: 143-distributed-storage-improvements.txt
> Title: Improvements of Distributed Storage for Tor Hidden Service
> Descriptors
> https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/143-distributed-storage-improvements.txt

This was not implemented, and is not worth trying to kludge onto the
current (v2) HS directory protocol.  I will re-read it before
specifying a new HS directory protocol.

> #155
> Filename: 155-four-hidden-service-improvements.txt
> Title: Four Improvements of Hidden Service Performance
> https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/155-four-hidden-service-improvements.txt

Part 1 was already implemented.  I reverted it as the first part of my
fixes for #1297, because it interacted very badly with Tor's adaptive
circuit-build timeout (introduced in 0.2.2.x).

I implemented Part 2 (with a different, CBT-derived time period before
retrying) as the second part of my fixes for #1297.

I don't know whether Part 3 was implemented.  I haven't seen it, but
it wouldn't belong in the code I'm familiar with (it should be in the
‘predicted circuit’ code).

Part 4 was already implemented.

> #194
> Filename: 194-mnemonic-urls.txt
> Title: Mnemonic .onion URLs
> https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/194-mnemonic-urls.txt

* This proposal is not specified thoroughly enough that it could be
  implemented in the near future.

* This proposal cannot be specified thoroughly enough to be
  implemented without significant effort for each language which it is
  intended to support.

* I do not believe that this proposal will be implementable without
  non-trivial code for each language which it is intended to support.

* Adding support to Tor for new hidden service address formats
  partitions Tor clients' anonymity sets.  Each language supported by
  this proposal will be a new hidden service address format; adding
  one new address format in each of several Tor versions is far worse
  than adding a few new address formats all at once.

* Once support for a language is added to Tor, it will be part of the
  Tor protocol, and *every* future implementation of the Tor protocol
  will need to include a copy of the associated dictionary.  It will
  not be possible to change a dictionary once it has become part of
  the Tor protocol.  This increases the minimum size of a Tor client,
  and also risks that an attacker could make malicious changes to the
  supported languages in order to make some of the phrases which Tor
  produces obscene or otherwise unprintable.

* Length limitations on DNS names and their components are likely to
  get in the way of extending this proposal to 255-bit hidden service
  names.

This proposal probably shouldn't be implemented in Tor.  It would be
easier and safer to implement in a separate utility, and it would
probably be more useful as a separate program from Tor as well.

> and also this inside of the ideas, that is loosely related to #194, but
> instead of offering
> an encoding it offers a petname system:
>
> Filename: xxx-onion-nyms.txt
> Title: .onion nym system
> https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-onion-nyms.txt

This is entirely unrelated to Tor -- it is a design for a tor2web
change, not a Tor change.  It shouldn't even have been added to
torspec.git.

This is also not a petname system -- the relying party is the user who
wants to connect to a service; a different party is trusted to
maintain name bindings honestly.  (Since this is a tor2web feature,
not a Tor feature, the fact that it relies on a trusted party does not
make users vulnerable to new attacks, because tor2web could screw the
user anyway.  But that doesn't make this naming system any better.)

> The single most important thing I believe is needed in Tor Hidden
> Service is Encrypted services.
> These can be seen, in a way, as the reverse of Tor2web mode. It allows
> people to publish Hidden Services
> with no anonymity, but have the Tor end-to-end encryption and
> performance improvements.

Anything which improves Tor for people who want anonymity is more
important than adding another non-anonymous mode.  (I wouldn't even
learn anything new about how HSes really work from implementing this
feature -- it's just a matter of making Tor build one-hop circuits for
its non-hidden services, then testing it and #ifdef-ing out asserts
until it works.)

I also think this feature belongs in a program separate from Tor --
many people and services would be interested in a system which
provides secure names and end-to-end authenticated and encrypted
connections, but are not interested in the other features that Tor
provides. Providing a separate system for ‘encrypted services’ would
keep the non-anonymous users and services from overloading Tor's
hidden service directories *and* allow its developers to play around
with a system with a much weaker threat model.  The proposal-194
naming system could be tested and deployed in that system without any
risk to Tor users' anonymity.

> I see these to be the future of what was previously done, poorly, with
> Tor Exit Enclaves. One that
> wishes to have an end-to-end encrypted tunnel from Tor clients can run
> an encrypted service and have
> a reduced number of hops from the IP and RP.

One of the major reasons for Tor's ‘exit enclave’ feature was to give
services an incentive to run Tor relays, thus contributing to the Tor
network rather than merely consuming its resources as a non-hidden
service would.

> Roger started writing up a spec on this and it can be found here:
>
> Filename: xxx-encrypted-services.txt
> Title: Encrypted services as a replacement to exit enclaving
> https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-encrypted-services.txt

This can be done without a spec change.

Robert Ransom