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

[teor]

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



-------------- 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/20170110/1c42a9b1/attachment.sig>