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

Tue Jan 3 04:45:50 UTC 2017

> On 29 Dec 2016, at 09:31, Micah Lee <micah at 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 at 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 at 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#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
------------------------------------------------------------------------

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