Configuring Single Onion Services
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. 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
Tim Wilson-Brown - teor <teor2345@gmail.com> writes:
[ text/plain ] 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.
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.
I think I like this approach more than complicating the torrc option name! Coming up with a warning message for people who forget to enable NonAnonymousMode seems easier than trying to fit that warning message in a torrc option name.
For whatever it's worth I never found the compile-time option for tor2web mode to be offensive. I remember Roger's original rebuttal against tor2web mode was, "Virgil, I'm not going to make a 'Make Tor Go Faster Button' to be pressed by people who don't know what they are doing." I always thought the compile-time-flag or text warning was a good compromise. -V On Friday, 8 April 2016, George Kadianakis <desnacked@riseup.net> wrote:
Tim Wilson-Brown - teor <teor2345@gmail.com <javascript:;>> writes:
[ text/plain ] 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.
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.
I think I like this approach more than complicating the torrc option name!
Coming up with a warning message for people who forget to enable NonAnonymousMode seems easier than trying to fit that warning message in a torrc option name.
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org <javascript:;> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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. 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
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. 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
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
David Goulet:
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.
I don't think using doubled option will force people to understand what's happening. Most probable outcome is that two-option requirement will look just "strange". It's strange because it's vague. I agree with David, something like "NonAnonymousOnionServiceMode 1" should be enough. It looks pretty clear and simple. [NB: a service cannot be Hidden and NonAnonymous at the same time :) ] -- Ivan Markin
On 12 Apr 2016, at 10:49, Ivan Markin <twim@riseup.net> wrote:
David Goulet:
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.
I don't think using doubled option will force people to understand what's happening. Most probable outcome is that two-option requirement will look just "strange". It's strange because it's vague. I agree with David, something like "NonAnonymousOnionServiceMode 1" should be enough. It looks pretty clear and simple. [NB: a service cannot be Hidden and NonAnonymous at the same time :) ]
We tried adding NonAnonymous to the name, and it was unwieldy. And it also confuses the semantics: what if we have multiple types of SingleOnionMode? Also, see my reply to David, where I explain that NonAnonymousMode applies to the entire tor instance, including things that are totally unrelated to Single Onion Services, like whether you can open a SOCKSPort or run Tor2Web. We could add a compilation option --enable-single-onion-mode instead of NonAnonymousMode, but I think making Single Onion Service operators compile their own tor is unnecessary. Tim
-- Ivan Markin _______________________________________________ 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
Tim Wilson-Brown - teor:
We tried adding NonAnonymous to the name, and it was unwieldy. And it also confuses the semantics: what if we have multiple types of SingleOnionMode?
If we do have multiple types of SingleOnionMode we should specify this type as a value to NonAnonymousOnionServiceMode option (or so). Why not? Sorry for my bias towards NonAnonymousOnions but SingleOnion really confuses me.
Also, see my reply to David, where I explain that NonAnonymousMode applies to the entire tor instance, including things that are totally unrelated to Single Onion Services, like whether you can open a SOCKSPort or run Tor2Web.
That's why I propose to use "NonAnonymousOnionServiceMode 1" instead of just "NonAnonymousMode 1".
We could add a compilation option --enable-single-onion-mode instead of NonAnonymousMode, but I think making Single Onion Service operators compile their own tor is unnecessary.
Gosh, it would be really inconvenient and nontransparent. And error-prone. -- Ivan Markin
participants (5)
-
David Goulet -
George Kadianakis -
Ivan Markin -
Tim Wilson-Brown - teor -
Virgil Griffith