Re: [tor-dev] Proposal: Single onion services
-------- Original Message -------- From: John Brooks <john.brooks@dereferenced.net> To: tor-dev@lists.torproject.org Subject: Re: [tor-dev] Proposal: Single onion services Date: Fri, 4 Sep 2015 15:31:15 -0600
tordev123@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).
tordev123@Safe-mail.net wrote:
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).
I see at least two important distinctions: 1) A single onion service is intentionally supporting tor users. Unlike an exit relay, you’re never connecting to anything that isn’t explicitly intended to accept tor. 2) The second middle relay in this circuit has no useful information - even less than an exit relay in a traditional circuit. I don’t think this role can be considered “exit-like” in any way. A single onion service is effectively part of the tor network, even if it’s not relaying other traffic. - special
participants (2)
-
John Brooks -
tordev123＠Safe-mail.net