'Re: [tor-dev] Configuring Single Onion Services'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tor-dev
Subject:    Re: [tor-dev] Configuring Single Onion Services
From:       David Goulet <dgoulet () ev0ke ! net>
Date:       2016-04-12 1:06:12
Message-ID: 20160412010612.GA13253 () raoul
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

On 12 Apr (10:48:37), Tim Wilson-Brown - teor wrote:
> 
> > On 12 Apr 2016, at 04:22, David Goulet <dgoulet@ev0ke.net> wrote:
> > 
> > On 08 Apr (10:15:19), Tim Wilson-Brown - teor wrote:
> > > Hi All,
> > > 
> > > I'm working on proposal 260's Rendezvous Single Onion Services in #17178.
> > > 
> > > They are faster, because they have one hop between the service and the \
> > > introduction and rendezvous points. But this means that their location is easy \
> > > to discover (non-anonymous). So we want to come up with a design that makes it \
> > > hard to configure a non-anonymous service by accident. 
> > > Here's a cut-down version of an email I sent to tor-onions for feedback, for \
> > > those who are on both lists: 
> > > Nick's concern was that users could configure Single Onion Services without \
> > > realising that it provides no server location anonymity. I initially thought we \
> > > could change the torrc option name to make this clear. ... I now believe that \
> > > trying to overload the name of a feature with warnings about its downsides was \
> > > a mistake. … 
> > > This would mean that Single Onion Service operators would include in their \
> > > torrc: 
> > > SingleOnionMode 1
> > > HiddenServiceDir …
> > > ...
> > > 
> > > As a separate issue, I think there are two alternative designs that can prevent \
> > > users from configuring the feature and then exposing their location \
> > > unintentionally: 
> > > Tor2WebMode requires users to add a compilation option: --enable-tor2web-mode
> > > We could do this with Single Onion Services as well: --enable-single-onion-mode
> > > If SingleOnionMode is configured without the compilation option, tor warns the \
> > > user and refuses to start. When it is configured, tor warns the user they're \
> > > non-anonymous, then starts. However, using a compilation option makes the \
> > > feature harder to test. And Tor2Web operators already don't like having to \
> > > compile separate binaries. It's likely Single Onion operators would feel \
> > > similarly. 
> > > Alternately, we could add a torrc option: NonAnonymousMode
> > > If SingleOnionMode is configured without NonAnonymousMode, tor warns the user \
> > > and refuses to start. When it is configured, tor warns the user they're \
> > > non-anonymous, then starts.
> > 
> > Just to be clear, the user would have to enable _both_ options to make the
> > single onion mode work? Like so:
> > 
> > SingleOnionMode 1
> > NonAnonymousMode 1
> > HiddenServiceDir ...
> > 
> > Basically asking the user to *explicitely" set an option that says "Ok you are
> > aware that you will loose anonymity".
> > 
> > It's a bit weird to have to enable two options for one feature (single onion)
> > BUT I like the double torrc option forcing the users to understand what's
> > going on (also adding semantic to the config file).
> > 
> > Bikesheding: the name though could be a bit misleading. What if that tor
> > process is also used as a client to "wget" stuff on the server for instance.
> > Won't I be confused if NonAnonymousMode is _set_ not knowing it applies to
> > what? Idea: "HiddenServiceNonAnonymousMode 1". Pretty explicit that it's for
> > the service.
> 
> Actually, NonAnonymousMode applies to the whole tor instance.
> 
> This was an issue we encountered a few months ago, and we decided that it's
> safer to prevent users from opening a SOCKSPort when SingleOnionMode is set.
> 
> Otherwise, the tor instance could be de-anonymised through the
> Single Onion Service, and that has implications for client anonymity as well.

Makes sense actually!

Great, then NonAnonymousMode sounds good to me in this case.

Thanks!
David

> 
> So the permitted combinations are:
> 
> Anonymous Client and Hidden Service
> Anonymous Client
> Hidden Service
> 
> Tor2WebMode and --enable-tor2web-mode and SingleOnionMode and NonAnonymousMode (I \
> can not imagine a use case for this) SingleOnionMode and NonAnonymousMode
> Tor2WebMode and --enable-tor2web-mode
> 
> Tim
> 
> > 
> > Cheers!
> > David
> > 
> > > 
> > > I spoke with Nick on IRC and he's happy with either of these options.
> > > 
> > > I'd like to proceed with the NonAnonymousMode torrc option, unless there are \
> > > compelling reasons against that design. I hope that this will allow us to get \
> > > SingleOnionMode merged early in tor 0.2.9. 
> > > Tim
> > > 
> > > Tim Wilson-Brown (teor)
> > > 
> > > teor2345 at gmail dot com
> > > PGP 968F094B
> > > ricochet:ekmygaiu4rzgsk6n
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > > _______________________________________________
> > > 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
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP 968F094B
> ricochet:ekmygaiu4rzgsk6n
> 
> 
> 

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

["signature.asc" (application/pgp-signature)]

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

[prev in list] [next in list] [prev in thread] [next in thread] 