Re: [tor-dev] non-anonymous ephemeral onion services with stem

[Roger Dingledine]

On Tue, Jan 30, 2018 at 11:03:26AM +1100, teor wrote:
> >> Ok, so you trust your friend with your IP and onion address in this use
> >> case.
> >> 
> >> But do you also trust the entire Tor network?
> > 
> > I opened a ticket for the OnionShare single onion service use case:
> > https://trac.torproject.org/projects/tor/ticket/21295
> > 
> > We'll see what we can do, and try to work out the anonymity implications
> > of leaking your IP address to the intro and rendezvous points.
> 
> I closed this ticket as "wontfix" with the following comment:
> 
> I just don't think this is safe, particularly as part of Tor's current
> design.

Agreed.

I think the trend of people saying "well I don't need anonymity" is no
different from the trend of people trying to justify their use of random
public proxies, VPNs, etc instead of Tor.

The fact is that people are often surprised to learn, after the fact when
it's too late and now they regret it, that they should have wanted some
more security. At Tor we should aim to give them that security by default,
and if they don't want it, we shouldn't give them an opportunity to think
"well I'm still using Tor so maybe I'm still making a good choice".

(I think this reasoning argues for jettisoning the whole single onion
service design too, but I won't try to make that argument in this thread.)

--Roger

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

Re: [tor-dev] non-anonymous ephemeral onion services with stem

[teor]

> On 24 Jan 2017, at 14:01, teor  wrote:
> 
> 
>> On 10 Jan 2017, at 09:17, teor  wrote:
>> 
>>> For example, maybe I want to use OnionShare to send my friend a 2GB
>>> video clip, but anonymity doesn't matter to me. My friend and I already
>>> know who each other are, and I'm not concerned about leaking what we're
>>> doing, I just don't want to leak the plaintext video footage. In this
>>> case, I might want to use a non-anonymous onion service just to make the
>>> file transfer faster.
>> 
>> Ok, so you trust your friend with your IP and onion address in this use
>> case.
>> 
>> But do you also trust the entire Tor network?
> 
> I opened a ticket for the OnionShare single onion service use case:
> https://trac.torproject.org/projects/tor/ticket/21295
> 
> We'll see what we can do, and try to work out the anonymity implications
> of leaking your IP address to the intro and rendezvous points.

I closed this ticket as "wontfix" with the following comment:

I just don't think this is safe, particularly as part of Tor's current
design.

We are adding vanguards to make onion services harder to discover.
And we want to reject connections to HSDir, intro, and rendezvous points
where there is a client directly connected on both sides.

If someone does want to give up their anonymity, they should run another
tor instance, or restart their current instance in non-anonymous mode.
Or we should develop a feature where controllers can set custom onion
service paths.

T

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n




signature.asc
Description: Message signed with OpenPGP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] non-anonymous ephemeral onion services with stem

[teor]

> On 4 Jan 2017, at 12:39, Micah Lee  wrote:
> 
> On 01/02/2017 08:45 PM, teor wrote:
>>> For my specific use-case, it would be great if you could pass an
>>> argument to ADD_ONION that makes that specific onion service
>>> non-anonymous, without changing anything globally.
>> 
>> What is the OnionShare use case?
>> What are the anonymity expectations of OnionShare users?
> 
> OnionShare is a tool to send files over the internet, so it can be used
> any time there's a need to do that. The security expectation is that the
> traffic can't be eavesdropped on by any attacker, but the anonymity
> expectation completely depends on the specific use case that it's being
> used for. I think it would be cool if there were an advanced option to
> let people use it to create non-anonymous onion services (the next
> version will include an advanced option to create stealth onion services).

I think it could have unexpected consequences for users, too.

When we were implementing Single Onion Services, we looked at many
differed use cases. But I don't think we considered the OnionShare one.

Our key concern was:

How do we introduce this new feature, but prevent users from
accidentally enabling it and exposing themselves?

> For example, maybe I want to use OnionShare to send my friend a 2GB
> video clip, but anonymity doesn't matter to me. My friend and I already
> know who each other are, and I'm not concerned about leaking what we're
> doing, I just don't want to leak the plaintext video footage. In this
> case, I might want to use a non-anonymous onion service just to make the
> file transfer faster.

Ok, so you trust your friend with your IP and onion address in this use
case.

But do you also trust the entire Tor network?

For example, I run a Tor Exit, and it is regularly subject to DDoS
attacks. Single Onion Services could be targeted by similar attacks.
(But it's less likely, because they do not send unencrypted traffic.)

Single Onion Services leak the service IP address to at least:
* 6 HSDirs,
* 3 Introduction Points,
* 1 Rendezvous Point,
and all the networks between the service and those relays.

(The nodes are chosen at random for each Single Onion Service
connection, so the chance of selecting a bad node or traversing a bad
network rapidly approaches 100%.)

They also link the IP and onion address at:
* 6 HSDirs.

(For next-generation hidden services, the situation is slightly better:

The IP leaks are the same, but the IP and onion address can only be
linked if the HSDirs already know the onion address.)

How would you document an advanced "Single Onion Service" option to
explain this loss of anonymity?
(We struggled with this.)

Is the speed increase for some users who know what they are doing, worth
the risk of other users losing anonymity unintentionally?

> For another example, pretend I'm a wanting to send a classified Word
> document to a journalist. In this case, I really care about anonymity,
> so I wouldn't want to use the non-anonymous option (if the journalist is
> tech savvy enough to edit their torrc file, I'd probably want to use a
> stealth one though).

Perhaps the best option is to restrict single onion services to those
tech savvy enough to edit their torrc file?

Although use of a text editor does not necessarily imply a deep
understanding of speed/source IP anonymity tradeoffs.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






signature.asc
Description: Message signed with OpenPGP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] non-anonymous ephemeral onion services with stem

[Micah Lee]

On 01/02/2017 08:45 PM, teor wrote:
>> For my specific use-case, it would be great if you could pass an
>> argument to ADD_ONION that makes that specific onion service
>> non-anonymous, without changing anything globally.
>
> What is the OnionShare use case?
> What are the anonymity expectations of OnionShare users?

OnionShare is a tool to send files over the internet, so it can be used
any time there's a need to do that. The security expectation is that the
traffic can't be eavesdropped on by any attacker, but the anonymity
expectation completely depends on the specific use case that it's being
used for. I think it would be cool if there were an advanced option to
let people use it to create non-anonymous onion services (the next
version will include an advanced option to create stealth onion services).

For example, maybe I want to use OnionShare to send my friend a 2GB
video clip, but anonymity doesn't matter to me. My friend and I already
know who each other are, and I'm not concerned about leaking what we're
doing, I just don't want to leak the plaintext video footage. In this
case, I might want to use a non-anonymous onion service just to make the
file transfer faster.

For another example, pretend I'm a wanting to send a classified Word
document to a journalist. In this case, I really care about anonymity,
so I wouldn't want to use the non-anonymous option (if the journalist is
tech savvy enough to edit their torrc file, I'd probably want to use a
stealth one though).
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] non-anonymous ephemeral onion services with stem

[teor]

> On 29 Dec 2016, at 09:31, Micah Lee  wrote:
> 
> On 12/28/2016 12:40 PM, Yawning Angel wrote:
>> On Wed, 28 Dec 2016 12:19:17 -0800
>> Micah Lee  wrote:
>> 
>>> And when other processes connect to the Tor control port and run
>>> create_ephemeral_hidden_service, those onion services wouldn't be
>>> non-anonymous?
>> 
>> They'll be non-anonymous (as in, the options are global).  This also
>> will not work if there is a SOCKS port configured.  Basically,
>> unless you are launching your own copy of the tor daemon, just for
>> non-anonymous HSes, it's a terrible idea to use these options in
>> general.
> 
> Thank you, this is good to know!
> 
> For my specific use-case, it would be great if you could pass an
> argument to ADD_ONION that makes that specific onion service
> non-anonymous, without changing anything globally.

What is the OnionShare use case?
What are the anonymity expectations of OnionShare users?

> But for the time-being I won't add support for non-anonymous onion
> services to OnionShare.

I can imagine an implementation where a one-shot single onion service
is used to transfer one file. But in this case, the user's IP address is
available to:
* the (service-chosen) introduction points, and
* the (client-chosen) rendezvous point(s).

This is true whether the single onion service is a separate tor instance
(the only mode permitted by the current implementation), or a service
making single-hop connections in the same tor instance as services
making multi-hop connections.

Here's a simple attack that de-anonymises some fraction of users using
this implementation:

1. Run some number of HSDirs and relays
2. When a new descriptor is received at your HSDir, set up a rendezvous
   to that service using your relay as a rendezvous point
3. If the IP address connecting to that relay is not in the consensus,
   it is probably a single onion service

(This attack is not possible with next-generation hidden services,
because HSDirs cannot decrypt the descriptor without knowing the
onion address.)

The single onion service implementation is designed to protect against
accidental exposure of onion service IP addresses via attacks like this.
It's designed for use cases where an expert administrator specifically
decides to disable responder anonymity, typically for performance.

It has the following semantics:

* the single onion service mode is global: it affects all services on a
  tor instance

If services can be correlated via side-channels (such as uptime), the IP
address of a single onion service could be linked to an anonymous
service on the same tor instance. (If multiple tor instances are running
on the same IP/machine/network, they can still be correlated, and this
mitigation does not affect that.)

* the single onion service mode can not be changed at runtime

This protects against linking past and future service connections, some
single-hop, some multi-hop.

* once a hidden service key (= .onion address) is generated in a
  particular anonymity mode, it can not be used in the other mode

This protects against the accidental re-use of an anonymous key in
single onion service mode, linking that key to an IP address.

> On 29 Dec 2016, at 07:24, Damian Johnson  wrote:
> 
> ...
> I thought those torrc options could only be set prior to tor starting
> up (like DisableDebuggerAttachment), but on reflection the manual
> doesn't say that so maybe that's not the case?

These option changes are not allowed at runtime, because apart from the
linkability issues, there is no way to change the number of hops in
existing hidden service connections, and the semantics are ill-defined:
It's not possible to turn a single-hop connection anonymous, and it's
not safe to make an anonymous connection single-hop.

And Damian is right: we have not been keeping
options_transition_allowed() in sync with the tor man page for some time.
Here is a fix:
https://trac.torproject.org/projects/tor/ticket/21122

> However, seems you also
> need to set 'SOCKSPort 0'...
> 
> https://www.torproject.org/docs/tor-manual.html.en#HiddenServiceNonAnonymousMode
> 
> If you call the above SETCONF does tor give any indication that you
> need to set the SOCKSPort too? If not then it feels like it should
> since that's pretty unintuitive.

When you set the option on startup, an appropriate warning about
SocksPort is issued. (Any SETCONF on these options fails
because changing them is not allowed.)

We decided not to disable the SOCKSPort automatically, because we
thought users might not like their SOCKSPort disappearing when an
unrelated option was set. Instead, we updated the documentation:
https://trac.torproject.org/projects/tor/ticket/20487

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

Re: [tor-dev] non-anonymous ephemeral onion services with stem

[Micah Lee]

On 12/28/2016 12:40 PM, Yawning Angel wrote:
> On Wed, 28 Dec 2016 12:19:17 -0800
> Micah Lee  wrote:
> 
>> And when other processes connect to the Tor control port and run
>> create_ephemeral_hidden_service, those onion services wouldn't be
>> non-anonymous?
> 
> They'll be non-anonymous (as in, the options are global).  This also
> will not work if there is a SOCKS port configured.  Basically,
> unless you are launching your own copy of the tor daemon, just for
> non-anonymous HSes, it's a terrible idea to use these options in
> general.

Thank you, this is good to know!

For my specific use-case, it would be great if you could pass an
argument to ADD_ONION that makes that specific onion service
non-anonymous, without changing anything globally.

But for the time-being I won't add support for non-anonymous onion
services to OnionShare.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] non-anonymous ephemeral onion services with stem

[Yawning Angel]

On Wed, 28 Dec 2016 12:19:17 -0800
Micah Lee  wrote:

> And when other processes connect to the Tor control port and run
> create_ephemeral_hidden_service, those onion services wouldn't be
> non-anonymous?

They'll be non-anonymous (as in, the options are global).  This also
will not work if there is a SOCKS port configured.  Basically,
unless you are launching your own copy of the tor daemon, just for
non-anonymous HSes, it's a terrible idea to use these options in
general.

Regards,

-- 
Yawning Angel


pgpA9Ze34XqQF.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] non-anonymous ephemeral onion services with stem

[Damian Johnson]

> Excellent. I'm pretty sure this will work, but can you confirm? If I'd
> like to use a non-anonymous ephemeral onion service, would code that's
> something like this work, assuming c is a Controller?
>
> c.set_conf('HiddenServiceSingleHopMode', 1)
> c.set_conf('HiddenServiceNonAnonymousMode', 1)
> c.create_ephemeral_hidden_service(8080)
>
> And when other processes connect to the Tor control port and run
> create_ephemeral_hidden_service, those onion services wouldn't be
> non-anonymous?

Good question. The non-anonymous torrc options are pretty clunky to
use. In part this is by design because the authors wanted to
discourage their use.

I thought those torrc options could only be set prior to tor starting
up (like DisableDebuggerAttachment), but on reflection the manual
doesn't say that so maybe that's not the case? However, seems you also
need to set 'SOCKSPort 0'...

https://www.torproject.org/docs/tor-manual.html.en#HiddenServiceNonAnonymousMode

If you call the above SETCONF does tor give any indication that you
need to set the SOCKSPort too? If not then it feels like it should
since that's pretty unintuitive.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] non-anonymous ephemeral onion services with stem

[Micah Lee]

On 12/28/2016 09:39 AM, Damian Johnson wrote:
> Oops, great catch - thanks Micah! Added a note saying how to use them...
> 
> "Version 1.5: Added support for non-anonymous services. To do so set
> 'HiddenServiceSingleHopMode 1' and 'HiddenServiceNonAnonymousMode 1'
> in your torrc."

Excellent. I'm pretty sure this will work, but can you confirm? If I'd
like to use a non-anonymous ephemeral onion service, would code that's
something like this work, assuming c is a Controller?

c.set_conf('HiddenServiceSingleHopMode', 1)
c.set_conf('HiddenServiceNonAnonymousMode', 1)
c.create_ephemeral_hidden_service(8080)

And when other processes connect to the Tor control port and run
create_ephemeral_hidden_service, those onion services wouldn't be
non-anonymous?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] non-anonymous ephemeral onion services with stem

[Damian Johnson]

Oops, great catch - thanks Micah! Added a note saying how to use them...

"Version 1.5: Added support for non-anonymous services. To do so set
'HiddenServiceSingleHopMode 1' and 'HiddenServiceNonAnonymousMode 1'
in your torrc."


On Wed, Dec 28, 2016 at 8:54 AM, Micah Lee  wrote:
> The stem documentation for create_ephemeral_hidden_service [1] says:
> "Changed in version 1.5.0: Added support for non-anonymous services."
>
> But I can't figure out to actually use this feature. There doesn't seem
> to be a new argument to say if you want your onion service to be
> non-anonymous.
>
> It also says, "Changed in version 1.5.0: Added the basic_auth argument."
> But there's a new basic_auth argument you can pass into the function to
> use that.
>
> [1]
> https://stem.torproject.org/api/control.html#stem.control.Controller.create_ephemeral_hidden_service
> ___
> 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