[tor-dev] Configuring Single Onion Services

[Tim Wilson-Brown - teor]

> On 12 Apr 2016, at 04:22, David Goulet <dgoulet at 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.

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160412/1f543946/attachment-0001.sig>