> On 4 Jan 2017, at 12:39, Micah Lee <micah@xxxxxxxxxxxxx> 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 ------------------------------------------------------------------------
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev