Hello,
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: https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypted...
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 here.
- 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 suggested here: https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html 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 Fast-but-not-hidden 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:
----
Filename: 244-direct-services.txt Title: Direct Onion Services: Fast-but-not-hidden services Author: Roger Dingledine, George Kadianakis Created: 2011-01-12 Status: Draft
1. Motivation
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 exit enclave.
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.
2. Design
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. Specification
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?
5. Future
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 [0]).