[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Proposal: Single onion services

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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev