Is there any way to reduce the length of a hidden service's path to the rendezvous point?

  1. Bob's hidden service <---> Introduction Point
  2. Alice <---> Introduction Point tell Bob to contact me at Rendezvous Point
  3. Bob <-> Rendezvous point

Sometimes, Bob's hidden service does not need anonymity, but wants to be accessible via Tor anyways. (For example, ahmia.fi is also accessible as msydqstlz2kzerdg.onion). In such a case, it might be beneficial to limit the length of Bob's circuit to 1 (as indicated by the length of the arrow in step 3). Is that possible?

This is similar to How to decrease number of Tor hops?. and Accessing Tor hidden services over a single hop circuit, but those wanted to limit the number of client hops. This question is about the number of server hops.


There are several amendments to Tor being researched to enable this functionality; the functionality does reduce/remove the anonymity of the server but sometimes that is okay, e.g. if (like Facebook) you run a publicly attested, non-hidden "onion service".*

The amendments are:

None of these are (at time of writing, January 2016) yet sedimented into the main Tor codebase, but they should be in the next few weeks/months.

As the above commenter almost suggests: you should consider carefully before enabling these features. From my experience running a publicly attested Onion, reduced server hop count does improve latency and makes Onion Services as performant, possibly a fraction more performant, than normal Tor. Your mileage may vary.

*Disclosure: I led the team which built the Facebook Onion Service

| improve this answer | |
  • Great answer. Seems like proposal 260 is what I explicitly asked for and 252 preceded it by another design which fulfills it just as well. Which one is used at facebook, if you may tell? – serv-inc Jan 19 '16 at 9:20
  • 1
    We ran totally stock, unmodified Tor code for the first year of operation to prove the concept. It worked fine, and was a simple introduction. We are now (Jan 2016) experimenting with RSOS (prop 260) and OnionBalance to scale the aggregate / net bandwidth available for people who want to use our Onion Service. – Alec Muffett Jan 19 '16 at 17:07
  • 2
    ps: you didn't ask this, but another relevant proposal is prop 255 "Controller features to allow for load-balancing hidden services" gitweb.torproject.org/torspec.git/tree/proposals/… - which is relevant to high-throughput load balancing of onions – Alec Muffett Jan 19 '16 at 17:13

Never decrease the hop length, because it's a purpose of having Tor entry point : to be censorship-resistant. If you will decrease your hidden service behaviour, you will not just decrease it's anonymity, but also make connections to it "fingerprintable"=detectable, and - as a consecuence - censorable

| improve this answer | |
  • 1
    Could you elaborate on how they are made detectable? – serv-inc Jan 18 '16 at 19:16
  • 1
    @user do you need a whitepaper or what exactly? – Alexey Vesnin Jan 19 '16 at 15:35
  • 1
    It's clear that this can deanonymize the hidden service. If you implied that it can deanonymize the client, what is your reasoning? – serv-inc Jan 19 '16 at 17:38
  • 1
    @user I suggest you better start reading here – Alexey Vesnin Jan 19 '16 at 17:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.