I agree as well and have discussed this use case with NRL colleagues for a while now. Some thoughts that we have had: 1. “Encrypted service” is a terrible name because it sounds like its only providing encryption and also is too generic. The idea needs a name that communicates that it is different from location-hidden services. Some ideas: “Tor-only service”, “Tor-aware service”, “Tor client-protected service”, and all of the preceding with “onion” in place of “Tor”. I’ll use “Tor-only service”. 2. Providing a Tor-only service would split the current anonymity set of hidden services to anybody that can distinguish such connections. Using timing and packet counting, this should be possible for any relay on the path between client and service, including especially the client’s guard. 3. A Tor-only service could actually use the fact that it’s location is not hidden for good: it could choose to place servers in strategic locations so that users could pick the ones that put them an minimum risk for traffic correlation, for example, by placing servers in a location with good rule of law and data privacy regulations.
Cheers, Aaron On Nov 25, 2014, at 5:43 PM, George Kadianakis <[email protected]> wrote: > Fabio Pietrosanti - lists <[email protected]> writes: > >> On 10/20/14 3:37 PM, George Kadianakis wrote: >>> Hello, >>> >>> this is an attempt to collect tasks that should be done for >>> SponsorR. You can find the SponsorR page here: >>> https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR >> [snip] >>> >>> == Performance Improvements == >>> >>> This is the most juicy section. How can we make HS performance better? >>> IIUC, we are mainly interested in client-side performance, but if a >>> change makes both sides faster that's even better. >> >> I suggest to consider also the so-called Tor2webMode to became a >> standard part of Tor as a way to improve Tor Hidden Services. >> >> While Tor2web Mode has born with the goal to reduce the number of hops >> for a Tor client used together with Tor2web software, it can provide >> great benefit also for TorHS owner. >> >> A TorHS owner MAY wish to be hidden in their location or not. >> >> If a TorHS owner enable Tor2web Mode, then it's assumed that he don't >> want "location anonymity" while preserving all other properties of TorHS >> (link-level encryption, self-authenticating URI, etc). >> >> With latest improvements of #12844 the performance of Tor2web Mode will >> be even better. >> >> For TorHS like Facebook or other resources that *does not need* location >> anonymity, having shorter circuit is a great performance improvement >> either in latency either in bandwidth. >> >> I would suggest/consider to introduce Tor2web mode (or something called >> differently) to be usable on stock Tor software, to enable quick >> optimization of TorHS owner that need performance by scarifying location >> anonymity . > > I fully agree that a server-side equivalent of Tor2web mode should be > made. The closest design we have so far is Roger's "encrypted > services" proposal: > https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-encrypted-services.txt > > Before implementation, the proposal needs some polishing and we should > think of any further optimizations that can be done (e.g. the > IP-equivalent of #12844 or something?). Implementation is not super > hard, but not trivial either. It will be great if we could do this as > part of SponsorR. > > Then, HSes with the Facebook threat model (who don't care about > location privacy) would be able to use this mode so that they are > faster and also cause less traffic to the network. > > _______________________________________________ > tor-dev mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
