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?
Have you considered all the implications?
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.
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. 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. 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.
Have you considered all the implications?
Maybe we’ve missed some - what implications are you thinking of, that aren’t addressed in the proposal?
Note that all tor relays are already willing to extend circuits to an arbitrary IP:port - that is not a new behavior, and it’s not thought to be dangerous.
- special
On Fri, 4 Sep 2015 15:31:15 -0600 John Brooks john.brooks@dereferenced.net wrote:
[snip]
Have you considered all the implications?
Maybe we’ve missed some - what implications are you thinking of, that aren’t addressed in the proposal?
I have two objections to this, one political, one technical:
* (The political objection) While this is "cool" and probably(?) "funded", it seems like a poor thing to work on in terms of developmental priority when there are other things Hidden Service related that need a lot of developer attention, primarily in making the existing HSes more resilient against Nation State level adversaries (Eg: Prop. 224).
* (The technical objection) It is overly easy for assholes[0] to censor Single Onion Services due to:
it’s possible for the previous relay to guess the service you’re connecting to
While such a censor would only be able to deny service to clients as a fraction of their relay(s) consensus weight, it's still something that probably should get consideration.
Regards,
Yawning Angel:
On Fri, 4 Sep 2015 15:31:15 -0600 John Brooks john.brooks@dereferenced.net wrote:
Have you considered all the implications?
Maybe we’ve missed some - what implications are you thinking of, that aren’t addressed in the proposal?
I have two objections to this, one political, one technical:
- (The political objection) While this is "cool" and probably(?) "funded", it seems like a poor thing to work on in terms of developmental priority when there are other things Hidden Service related that need a lot of developer attention, primarily in making the existing HSes more resilient against Nation State level adversaries (Eg: Prop. 224).
We should definitely have a Tor roadmapping session at the dev meeting to cover this and related concerns.
I too have been worrying about the drift between what we suspect are the most serious problems in the hidden service protocol (and the Tor protocol in general) and the current set of Tor deliverables and dev plans (or lack thereof).
OTOH, in order to make proper roadmapping, priority, and work-ordering decisions, we really do need a good menu of well-written proposals and/or tickets to choose from, even if we're likely to decide some of them are simply not worth doing yet until other issues are solved first.
Otherwise roadmapping will become a bunch of hand-wavy statements about "Well, what about trying to solve $ISSUE_X $SOMEHOW?" without the ability to weigh the efficacy of a specific solution and how its development effort compares to (or depends upon) the gains from other potential improvements.
(The technical objection) It is overly easy for assholes[0] to censor Single Onion Services due to:
it’s possible for the previous relay to guess the service you’re connecting to
While such a censor would only be able to deny service to clients as a fraction of their relay(s) consensus weight, it's still something that probably should get consideration.
In addition to this concern, I am also wondering about the second-order effects of what happens when we have two classes of internal services: the "boring" ones that don't use the full rend protocol, and the "interesting" ones that do, especially if we still have not solved the circuit setup fingerprinting problem to prevent an observer from easily differentiating the two before this (or a similar mechanism) is deployed.
On 05 Sep (14:47:41), Mike Perry wrote:
Yawning Angel:
On Fri, 4 Sep 2015 15:31:15 -0600 John Brooks john.brooks@dereferenced.net wrote:
Have you considered all the implications?
Maybe we’ve missed some - what implications are you thinking of, that aren’t addressed in the proposal?
I have two objections to this, one political, one technical:
- (The political objection) While this is "cool" and probably(?) "funded", it seems like a poor thing to work on in terms of developmental priority when there are other things Hidden Service related that need a lot of developer attention, primarily in making the existing HSes more resilient against Nation State level adversaries (Eg: Prop. 224).
We should definitely have a Tor roadmapping session at the dev meeting to cover this and related concerns.
+9000
I too have been worrying about the drift between what we suspect are the most serious problems in the hidden service protocol (and the Tor protocol in general) and the current set of Tor deliverables and dev plans (or lack thereof).
OTOH, in order to make proper roadmapping, priority, and work-ordering decisions, we really do need a good menu of well-written proposals and/or tickets to choose from, even if we're likely to decide some of them are simply not worth doing yet until other issues are solved first.
Otherwise roadmapping will become a bunch of hand-wavy statements about "Well, what about trying to solve $ISSUE_X $SOMEHOW?" without the ability to weigh the efficacy of a specific solution and how its development effort compares to (or depends upon) the gains from other potential improvements.
Last hidden service meeting in July, we were able to come up with a breakdown of components for 224. See the blog post we did a month ago:
https://blog.torproject.org/blog/hidden-service-hackfest-arlington-accords
More specifically:
Splitting 224 into "modules": https://people.torproject.org/~asn/hs_hackfest_2015/224modules.txt
and:
Needed code refactor: https://people.torproject.org/~dgoulet/hs224-refactor.txt
This is clearly not as organised as it could be but I think it's a good base from which we start on;
If the modules above make sense, having a ticket (or a family of tickets) for them and proposals (if applicable) is definitely a way to go forward that I agree on. Good example, proposal #250.
Let's have a session for that in Berlin for sure! Ideally, having an agenda before we start would be fantastic. I'll try to start tomorrow a wiki page about it and we can start from there until Berlin.
Thanks! David
(The technical objection) It is overly easy for assholes[0] to censor Single Onion Services due to:
it’s possible for the previous relay to guess the service you’re connecting to
While such a censor would only be able to deny service to clients as a fraction of their relay(s) consensus weight, it's still something that probably should get consideration.
In addition to this concern, I am also wondering about the second-order effects of what happens when we have two classes of internal services: the "boring" ones that don't use the full rend protocol, and the "interesting" ones that do, especially if we still have not solved the circuit setup fingerprinting problem to prevent an observer from easily differentiating the two before this (or a similar mechanism) is deployed.
-- Mike Perry
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hello,
Nice, concise proposal! I’ve been meaning for a while to send some comments:
Overall: 1. This proposal doesn’t allow you to run a single-onion service if your server is behind NAT. It might be useful to include an option for the SOS to create persistent connections to some guards that will also serve as rendezvous points. 2. This proposal doesn’t allow a single-onion services to hide its existence. It is possible to hide its existence unless you know enough to request the descriptor, but it would seem to require using guards or a malicious relay will eventually be selected to connect directly to the SOS. 3. I suggest using “single-onion service” throughout because it makes it clear that “single” modifies “onion” and not “onion service”. I disagree with the suggestion from Jeff Burdges that this term is “grammatically” inaccurate. At worst, it might suggest that only a “single onion” is ever used. However, Tor actually doesn’t use onions at all, which I can only understand to mean repeatedly-encrypted data structures that contain no actual payload. So “onion routing” is just as inaccurate. “Single onion” to me refers to the use of a multiply-encrypted tunnel from a “single” member of the communicating pair, and I think that works just fine. 4. To respond to the suggestion by Jeff Burdges, I wouldn’t prefer “Directly Peered Rendezvous Service”, because it is cumbersome (intentionally, I understand), and it will need to be used frequently at least to remind people what the unintuitive “DPR” acronym refers to. I also rather dislike the collision with “Dread Pirate Roberts” of Silk Road fame, which I would rather not steer Tor into.
Sec 5.1: "Configuration options… RelayAllowExtend 0|1 If set, allow clients to extend circuits from this relay… PublishServerDescriptor must also be disabled if this option is disabled… If ExitRelay is also disabled, this relay will not pass through any traffic.”
This doesn’t make sense to me. By "allow clients to extend circuits from this relay” I take RelayAllowExtend to indicate that a relay will extend circuit *through* itself. But then why should it be that "PublishServerDescriptor must also be disabled if this option is disabled”? Wouldn’t you want to disable RelayAllowExtend and enable PublishServerDescriptor to run a single onion service? Also, the statement that "If ExitRelay is also disabled, this relay will not pass through any traffic.” makes it seem like it is required to disable ExitRelay in order to prohibit passing through any traffic. However, my reading of the definition of RelayAllowExtend makes it seem like disabling RelayAllowExtend is all that is required to prohibit passing through any traffic, and
Sec. 7.1: "To prevent this, we would need to include a cookie from the descriptor in the RELAY_BEGIN information.”
It does seem helpful to be able to use an authentication cookie to prevent this attack, although single onion services shouldn’t expect their existence and location to remain unknown because they don't use guards (under this proposal). With enough connections, any one of them would eventually be connected to by every middle, including malicious ones trying to enumerate single onion services. However, SOSes could still hide what the server does by including the authentication cookie, and that seems valuable. Isn’t authentication already an option in onion services, though?
Cheers, Aaron
On Sep 6, 2015, at 3:21 AM, David Goulet dgoulet@ev0ke.net wrote:
On 05 Sep (14:47:41), Mike Perry wrote:
Yawning Angel:
On Fri, 4 Sep 2015 15:31:15 -0600 John Brooks john.brooks@dereferenced.net wrote:
Have you considered all the implications?
Maybe we’ve missed some - what implications are you thinking of, that aren’t addressed in the proposal?
I have two objections to this, one political, one technical:
- (The political objection) While this is "cool" and probably(?) "funded", it seems like a poor thing to work on in terms of developmental priority when there are other things Hidden Service related that need a lot of developer attention, primarily in making the existing HSes more resilient against Nation State level adversaries (Eg: Prop. 224).
We should definitely have a Tor roadmapping session at the dev meeting to cover this and related concerns.
+9000
I too have been worrying about the drift between what we suspect are the most serious problems in the hidden service protocol (and the Tor protocol in general) and the current set of Tor deliverables and dev plans (or lack thereof).
OTOH, in order to make proper roadmapping, priority, and work-ordering decisions, we really do need a good menu of well-written proposals and/or tickets to choose from, even if we're likely to decide some of them are simply not worth doing yet until other issues are solved first.
Otherwise roadmapping will become a bunch of hand-wavy statements about "Well, what about trying to solve $ISSUE_X $SOMEHOW?" without the ability to weigh the efficacy of a specific solution and how its development effort compares to (or depends upon) the gains from other potential improvements.
Last hidden service meeting in July, we were able to come up with a breakdown of components for 224. See the blog post we did a month ago:
https://blog.torproject.org/blog/hidden-service-hackfest-arlington-accords
More specifically:
Splitting 224 into "modules": https://people.torproject.org/~asn/hs_hackfest_2015/224modules.txt
and:
Needed code refactor: https://people.torproject.org/~dgoulet/hs224-refactor.txt
This is clearly not as organised as it could be but I think it's a good base from which we start on;
If the modules above make sense, having a ticket (or a family of tickets) for them and proposals (if applicable) is definitely a way to go forward that I agree on. Good example, proposal #250.
Let's have a session for that in Berlin for sure! Ideally, having an agenda before we start would be fantastic. I'll try to start tomorrow a wiki page about it and we can start from there until Berlin.
Thanks! David
(The technical objection) It is overly easy for assholes[0] to censor Single Onion Services due to:
it’s possible for the previous relay to guess the service you’re connecting to
While such a censor would only be able to deny service to clients as a fraction of their relay(s) consensus weight, it's still something that probably should get consideration.
In addition to this concern, I am also wondering about the second-order effects of what happens when we have two classes of internal services: the "boring" ones that don't use the full rend protocol, and the "interesting" ones that do, especially if we still have not solved the circuit setup fingerprinting problem to prevent an observer from easily differentiating the two before this (or a similar mechanism) is deployed.
-- Mike Perry
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Yawning Angel yawning@schwanenlied.me wrote:
I have two objections to this, one political, one technical:
- (The political objection) While this is "cool" and probably(?) "funded", it seems like a poor thing to work on in terms of developmental priority when there are other things Hidden Service related that need a lot of developer attention, primarily in making the existing HSes more resilient against Nation State level adversaries (Eg: Prop. 224).
I agree that 224 and improvements to “double onion services” are much more important.
On the other hand, the goal of single onion services is to encourage more use of onion services in general, especially by large scale normal-web services. Bringing those new services and the extra attention can hopefully help improve the perception of the onion services in general, and possibly help with funding them.
(The technical objection) It is overly easy for assholes[0] to censor Single Onion Services due to:
it’s possible for the previous relay to guess the service you’re connecting to
While such a censor would only be able to deny service to clients as a fraction of their relay(s) consensus weight, it's still something that probably should get consideration.
Yes, we should address this. Is retrying through a new circuit after circuit failures sufficient, or do we need something more sophisticated?
As a countermeasure, a single onion service can choose to also act as a tor relay. In that case, the censor relay should not be able to easily distinguish between relay traffic and the single onion traffic.
- special
As an aside, we chatted briefly about the naming options for single onion services or whatever at CCC camp. Amongst those present, there was no strong love for any existing naming proposal. An interesting naming idea surfaced however :
We do not want people using these anyways unless they know what they're doing. So why not use a scary opaque acronym to tempt anyone interested to actually read the documentation?
An obvious choice is Directly Peered Rendezvous Services, or DPR Services for short, with the config option name DPRService.
It flows relatively well in conversation and contains no grammatically mess. Single onion services is grammatically amiss. I suppose single-layer onion service might work, but that's still confusing logically. Importantly, it does not encourage improper usage like Fast-but-not-hidden services might.
I suppose one might use Direct Peered Rendezvous Service too, not 100% sure on the optimal form for typical English grammar there.
Best, Jeff
p.s. At camp, we first discussed the name Direct Point Rendezvous Services, but the acronym would be the same.
;)
p.s. I'm thinking of this now partially because the discussion between Yawning, Mike, and David seems to rest partially on such services being handled like introduction points or like rendezvous points. I'd just assumed they needed to be handled like rendezvous points to defend against attacks like Yawning mentioned.
-
Aaron Johnson -
David Goulet -
Jeff Burdges -
John Brooks -
Mike Perry -
tordev123＠Safe-mail.net -
Yawning Angel