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?

On 29 Dec 2016, at 09:31, Micah Lee micah@micahflee.com wrote:

On 12/28/2016 12:40 PM, Yawning Angel wrote:

...

On Wed, 28 Dec 2016 12:19:17 -0800 Micah Lee micah@micahflee.com 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 atagar@torproject.org 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#HiddenServiceNonAnonymous...

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 ------------------------------------------------------------------------

On 4 Jan 2017, at 12:39, Micah Lee micah@micahflee.com 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 ------------------------------------------------------------------------

On 10 Jan 2017, at 09:17, teor teor2345@gmail.com 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.

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 ------------------------------------------------------------------------

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

On 12/28/2016 12:40 PM, Yawning Angel wrote:

On Wed, 28 Dec 2016 12:19:17 -0800 Micah Lee micah@micahflee.com 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.