Finish 'encrypted services' proposal
Many hidden services use the hidden service design for its incidental properties, such as end-to-end encryption, self-authenticating names, and usability properties of knowing you're going through Tor. They suffer from the performance and robustness issues of hidden services when (maybe) they don't need to.
We should offer a way to run a Tor hidden service where the server-side rendezvous circuits are just one hop.
Step one is to finish the proposal.
Activity
changed milestone to %Tor: 0.2.8.x-final
Ok, I committed a start at the proposal in 6ce217731 aka https://git.torproject.org/tor/doc/spec/proposals/ideas/xxx-encrypted-services.txt
I'm taking this off of #2552 (moved) since it wouldn't actually be helpful to tor2web and since #2553 (moved) accurately describes the thing that would be helpful. It's possible #2553 (moved) could be a subset of a larger version of this, of course.
Trac:
Parent: #2552 (moved) to N/A
[duplicate ticket #15271 (moved) also has some thoughts.]
Trac:
Cc: N/A to lists@infosecurity.chGiven that this implementation enable exposure of NON-ANONYMOUS Tor Hidden Service with the standard Tor software, i think that it make sense to enable also NON-ANONYMOUS Tor Hidden Service Client (ie: Actually compile-time Tor2web Mode) with the standard Tor software.
For both NON-ANONYMOUS Tor Hidden Service use-cases (Server and Client), we can build them in the standard version of Tor by adding a command line like:
- --yes-i-know-that-i-m-going-to-use-non-anonymous-tor-hidden-services-client (tor2web mode)
- --yes-i-know-that-i-m-going-to-use-non-anonymous-tor-hidden-services-server (encrypted services)
That way the Tor Hidden Services world will have it's NON-ANONYMOUS way to use Tor Darknet with the Server (encrypted services) and Client (tor2web mode).
I strongly advocate for that approach! :*
/cc @virgilgriffith @evilaliv3
Trac:
Cc: lists@infosecurity.ch to lists@infosecurity.ch, virgilgriffith, evilaliv3, teor-
I've heard some interesting variations on this design recently, including one where the onion service descriptor simply lists the extend_info details (IP, port, fingerprint, onion key) for a relay that is where you should extend to ask for this service. (The relay wouldn't have to advertise itself in the consensus.)
Replying to arma:
I've heard some interesting variations on this design recently, including one where the onion service descriptor simply lists the extend_info details (IP, port, fingerprint, onion key) for a relay that is where you should extend to ask for this service. (The relay wouldn't have to advertise itself in the consensus.)
This is one of the proposed changes for one-ion services (client-anonymous, server-known hidden services). The unadvertised relay would be on the same network or box as the hidden service, like the server equivalent of the client option Tor2WebRendezvousNodes.
Replying to naif:
@arma what do you think about getting both non-anonymous Tor HS Server (encrypted-services) and client (Tor2web mode) into the standard release Tor, by renaming it properly, introducing ton of explicit warning and configuration settings to enable it?
For non-anonymous Tor HS Servers, I've created a branch which connects directly to the rendezvous point (rather than a 3-hop path, then the rendezvous point for anonymous servers). For testing purposes, the number of relays between server and RP can be configured at any value between 0 and 8. (Anonymous servers use 3 relays between server and HS, or 4 if the circuit is cannibalized.)
This code could be simplified and expanded to:
- Connect directly to the HSDir (0 relays between server and HSDir)
- Connect directly to the IP (0 relays between server and IP)
- Connect directly to the RP (0 relays between server and RP)
- Optionally: nominate the HSDirs as IPs, allowing server and client connection re-use. This may have privacy and load implications, and give HSDirs even more power than they already have. We'd need to consider the implications for client anonymity carefully.
- Optionally: set up the non-anonymous server and a relay on the same box, and nominate the relay as the IP. Again, privacy implications.
As far as I understand, this is the maximum set of backwards-compatible changes we can make to server anonymity.
The test branch for server RP route lengths is here:
Repository: https://github.com/teor2345/tor.git Branch: hs-route-len
There are test services running on my EC2 box with route lengths 0-8. Route length 0 (non-anonymous server) is at http://chhcrih6hum7anjw.onion:10000/
For Tor2Web (non-anonymous clients), some of the equivalent features are already implemented:
- Nominate the Tor2Web server as the RP relay (one hop between client and RP, and this hop can be on localhost if the Tor2Web box is configured as a relay)
- The option
Tor2webRendezvousPointsis like this, but also has a random fallback node selection feature which may impact anonymity:If no nodes in Tor2webRendezvousPoints are currently available for use, Tor will choose a random node when building HS circuits.
- The option
I don't know the status of these Tor2Web features:
- Connect directly to the HSDir (0 relays between client and HSDir)
- Connect directly to the IP (0 relays between client and IP)
- And, optionally: nominate the IPs as RPs, allowing server and client connection re-use. This may have privacy and load implications, and give IPs/RPs more power than they already have. We'd need to consider the implications for server anonymity carefully.
As far as I understand, this is the maximum set of backwards-compatible changes we can make to client anonymity.
I think that pretty much covers it, but I'm still working out some of the details.
https://gitweb.torproject.org/user/special/torspec.git/log/?h=xxx-direct-onion exists . We should ask special how far away it is from wanting a proposal number :)
mentioned in issue #5641 (moved)
mentioned in issue #15271 (moved)
mentioned in issue #17019 (moved)
moved to tpo/core/tor#2555 (closed)
mentioned in issue tpo/core/tor#5641 (closed)
mentioned in issue tpo/core/tor#17019 (closed)
