Opened 9 years ago

Closed 4 years ago

Last modified 4 years ago

#2555 closed task (fixed)

Finish 'encrypted services' proposal

Reported by: arma Owned by: special
Priority: High Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Keywords: tor-hs, 027-triaged-1-in
Cc: lists@…, virgilgriffith, evilaliv3, teor Actual Points:
Parent ID: Points: small
Reviewer: Sponsor: SponsorR

Description

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.

Child Tickets

Change History (28)

comment:1 Changed 9 years ago by arma

Ok, I committed a start at the proposal in 6ce217731 aka
https://git.torproject.org/tor/doc/spec/proposals/ideas/xxx-encrypted-services.txt

comment:2 Changed 9 years ago by arma

Component: Tor ClientTor hidden services

comment:3 Changed 9 years ago by aaronsw

Parent ID: #2552

I'm taking this off of #2552 since it wouldn't actually be helpful to tor2web and since #2553 accurately describes the thing that would be helpful. It's possible #2553 could be a subset of a larger version of this, of course.

comment:4 Changed 8 years ago by rransom

Owner: changed from arma to rransom
Status: newassigned

comment:5 Changed 8 years ago by nickm

Milestone: Tor: unspecified

comment:6 Changed 7 years ago by nickm

Keywords: tor-hs added

comment:7 Changed 7 years ago by nickm

Component: Tor Hidden ServicesTor

comment:8 Changed 5 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.7.x-final

These go in Tor 0.2.7

comment:9 Changed 4 years ago by nickm

Keywords: 027-triaged-1-in added

Marking some tickets as triaged-in for 0.2.7 based on early triage

comment:10 Changed 4 years ago by isabela

Keywords: SponsorR added
Points: small
Priority: normalmajor
Version: Tor: 0.2.7

comment:11 Changed 4 years ago by asn

[duplicate ticket #15271 also has some thoughts.]

comment:12 Changed 4 years ago by naif

Cc: lists@… added

comment:13 Changed 4 years ago by naif

Given 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! :*

Last edited 4 years ago by naif (previous) (diff)

comment:14 Changed 4 years ago by naif

/cc @virgilgriffith @evilaliv3

comment:15 Changed 4 years ago by teor

Cc: virgilgriffith evilaliv3 teor added

comment:16 Changed 4 years ago by 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.)

comment:17 in reply to:  16 Changed 4 years ago by teor

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.

comment:18 Changed 4 years ago by 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?

comment:19 in reply to:  18 Changed 4 years ago by teor

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 Tor2webRendezvousPoints is 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.

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.

comment:20 Changed 4 years ago by nickm

Keywords: TorCoreTeam201507 added

comment:21 Changed 4 years ago by nickm

Owner: changed from rransom to special

comment:22 Changed 4 years ago by nickm

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 :)

comment:23 Changed 4 years ago by nickm

Keywords: TorCoreTeam201507 removed

comment:24 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:25 Changed 4 years ago by arma

It is now proposal 252.

comment:26 Changed 4 years ago by arma

(Hey, does that mean we finished this ticket? :)

comment:27 in reply to:  26 Changed 4 years ago by special

Resolution: fixed
Status: assignedclosed

Replying to arma:

(Hey, does that mean we finished this ticket? :)

Yes, I think so.

Should we delete the torspec/proposals/ideas/xxx-encrypted-services.txt file now?

comment:28 Changed 4 years ago by dgoulet

Keywords: SponsorR removed
Sponsor: SponsorR
Note: See TracTickets for help on using tickets.