Re: [tor-bugs] #2555 [Tor]: Finish 'encrypted services' proposal

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#2555: Finish 'encrypted services' proposal
-----------------------+------------------------------------------------
     Reporter:  arma   |      Owner:  rransom
         Type:  task   |     Status:  assigned
     Priority:  major  |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor    |    Version:  Tor: 0.2.7
   Resolution:         |   Keywords:  tor-hs, 027-triaged-1-in, SponsorR
Actual Points:         |  Parent ID:
       Points:  small  |
-----------------------+------------------------------------------------

Comment (by teor):

 Replying to [comment:18 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2555#comment:19>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs