[tor-dev] Proposal: Single onion services

[tordev123 at Safe-mail.net]

-------- Original Message --------
From: John Brooks <john.brooks at dereferenced.net>
To: tor-dev at lists.torproject.org
Subject: Re: [tor-dev] Proposal: Single onion services
Date: Fri, 4 Sep 2015 15:31:15 -0600

> tordev123 at Safe-mail.net wrote:
> 
> > Doesn't your proposal imply that you are turning all relays into
> > exit-nodes lite? The last relay in the path will know what service you are
> > connecting to (at least if that service is hosted with a unique relay),
> > right?
> 
> A single onion service operates its own server(s). These servers accept OR
> connections like a relay does, but they aren’t required to be in the
> consensus or to relay traffic. They are the servers listed in the
> descriptor.

Right, that's how I understood things.

> A client connects by extending a circuit to the single onion server. This is
> not the same as an exit connection: tor relays will extend circuits to
> relays they don't know about, as long as the destination speaks the tor
> protocol. It’s possible for any tor relay to be used as the last one before
> the single onion server.
> 
> If the single onion server isn’t also a tor relay, it’s possible for the
> previous relay to guess the service you’re connecting to.

That is a large part of my concern.

> This isn’t a risk
> to client anonymity, because tor clients will always choose the first three
> hops in a circuit before extending to one they didn’t choose.

I'm not concerned about clients.

> The final circuit looks like:
> 
> Client -> Guard -> Middle -> Middle -> Single Onion
> 
> The client’s traffic is encrypted through to the single onion server as
> well.

IMO, the second Middle relay can be considered serving as an exit with regards to Single Onion services - that's what I meant with 'exit node lite'.

There was the case of an Austrian exit node operator getting prosecuted. It will sometimes be possible to attribute traffic relating to specific transactions to the second Middle node in the path (e.g. when the single onion server keeps detailed logs). So the circumstances of that case could apply to a non-exit relay operator as well.

Your proposal is shifting non-exit relays towards performing a role that can be considered exit-like, even if that role is much more limited than normal exits (and there is an additional Tor protocol layer involved).