> On 29 Dec 2016, at 09:31, Micah Lee <micah@xxxxxxxxxxxxx> wrote: > > On 12/28/2016 12:40 PM, Yawning Angel wrote: >> On Wed, 28 Dec 2016 12:19:17 -0800 >> Micah Lee <micah@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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 ------------------------------------------------------------------------
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