[tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"
desnacked at riseup.net
Thu Apr 9 18:58:49 UTC 2015
I inline a proposal for Direct Onion Services. It's heavily based on
the "encrypted services" proposal of Roger, but I refined it, made it
more proposaley and enabled a few more optimizations. You can find the
original piece here:
Feedback would be greatly appreciated.
Here are some specific points that I would like help with:
- Should we require a specially compiled version of Tor to enable this
feature? Like we do for tor2web mode? In this proposal, I didn't
require any special compilation flags. I don't have strong opinions
- We really really need a better name for this feature. I decided to
go with "Direct Onion Services" which is the one that the NRL people
I'm not super happy with it, but I can't think of better ones myself.
Here are some candidates:
1 Way Anonymous Hidden Services
Fast Onion Service
Short-circuited Onion Services
- We also need a better torrc option. If the name of this feature does
not portray its dangers, then the torrc option should be a bit
terrifying. That's why I went 'DangerousDirectOnionService' which I
actually don't like at all. BTW, it's unclear whether this mailing
list is the best place to brainstorm for names.
Here goes proposal:
Title: Direct Onion Services: Fast-but-not-hidden services
Author: Roger Dingledine, George Kadianakis
Hidden services can cover multiple use cases and threat models. They
offer server-side anonymity by default because that's the most
common use case, but there also hidden service users who don't
really need service-side anonymity.
This proposal aims to satisfy those users by introducing an optional
opt-in feature that *sacrifices server-side anonymity* *for better
performance*. Client-side anonymity will still be preserved as normal.
Here are some use cases that this idea addresses:
1) Indymedia wants to run an exit enclave that provides end-to-end
authentication and encryption. They tried running an exit relay
that just exits to themselves (#800) but
* it handles lots of other traffic too since it's a relay
* exit enclaves don't actually work consistently, because the
first connection from the user doesn't realize it should use the
2) Wikileaks uses Tor hidden services not to hide their service, but
because the hidden service address provides a type of usability
we didn't think much about: unlike a more normal address, a Tor
hidden service address either works (meaning you get your
end-to-end authentication and encryption) or it fails hard. With
a hidden service address there's no way a user could accidentally
submit their documents to Wikileaks without using Tor, but with
normal Tor it's possible.
3) The Freenode IRC network wants to provide end-to-end encryption
and authentication to its users, a) to handle the fact that the
IRC protocol doesn't really provide much of that by default, and
b) to funnel all their Tor users into a single location so they
can handle the anonymous users better. They don't mind the fact
that their service is hidden, but they'd rather have better
performance for their users given the choice.
As a side-effect, by optimizing for performance in this feature, it
allows us to lean more heavily towards security decisions for
regular onion services.
We suggest the following changes to be implemented:
i. Add a way in the torrc file to specify that this service wants
to be an encrypted service rather than a hidden service. [TORRC]
ii. An encrypted service SHOULD establish 1-hop circuits to its
introduction points. [ONEHOP]
iii. An encrypted service SHOULD establish 1-hop circuits to
rendezvous points [ONEHOP].
iv. An encrypted service MAY NOT use static guard nodes [NOGUARDS].
More information about these steps can be found in the next section.
3.1. Torrc configuration parameter [TORRC]
To enable this optional feature, we introduce the boolean
DangerousDirectOnionService torrc option. The option MUST be
*disabled by default*.
Because of the grave consequences of misconfiguration here, we have
prepended the torrc option with 'Dangerous'. Furthermore, Tor MUST
issue a startup warning message to operators of the hidden service
if this feature is enabled.
3.2. One-hop circuits [ONEHOP]
When in this mode, the onion service establishes 1-hop circuits to
introduction and rendezvous points. The onion service SHOULD also
ignore cannibalizable 3-hop circuits when creating such circuits.
This looks like this for the rendezvous point case:
|direct onion service| -> RP <- client middle <- client guard <- |client|
This change allows greater speeds when establishing a hidden service
circuit and reduces round-trip times. As a side-effect, busy onion
services with this feature cause less damage to the rest of the
network, since their traffic gets passed around less.
3.3. Disable guard nodes [NOGUARDS]
Entry guards are a security measure against Sybil attacks.
Unfortunately, they also act as the bottleneck of busy hidden
services and overload those Tor relays.
This proposal suggests disabling the entry guard feature entirely
when this mode is enabled. This allows the hidden service to split
its traffic out to multiple relays on the network.
4. Security implications
There's a possible second-order effect here since both encrypted
services and hidden services will have foo.onion addresses and it's
not clear based on the address whether the service will be hidden --
if *some* .onion addresses are easy to track down, are we encouraging
adversaries to attack all rendezvous points just in case?
Here are some thoughts on things we could look in the future to
further optimize performance when this mode is enabled:
- We should look whether we can optimize further the preemptive
circuits that Tor makes as a hidden service.
- We could also make hidden services determine the number of
introduction points based on their popularity, to allow greater
load balancing. This has the potential for leaking the popularity
of hidden services (#4862), but maybe this is not a concern when
this mode is enabled.
- For this mode, we could look into alternative designs where a
rendezvous step is not needed, and the traffic gets routed through
the introduction points (as in Valet nodes ).
More information about the tor-dev