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