On Mon, Feb 16, 2015 at 03:47:07PM +0000, Yawning Angel wrote: > On Mon, 16 Feb 2015 10:17:51 -0500 > David Goulet <dgou...@ev0ke.net> wrote: > [snip] > > A hidden service is created using the key and list of > > port/targets, that will persist till configuration reload or the > > termination of the tor process. > > > > Now, an HS bound to a control connection might be a good idea, I'm not > > 100% sure but I can see issues with this. Let's say > > "ControlListenAddress" is used, this means a TCP socket and it can > > timeout if no activity, so if that happens, I loose my HS? > > That's correct, though unless tor or the controller library has code to > stomp on long dormant connections (which a casual look says there > isn't), this shouldn't happen, because TCP/IP in itself has no idle > timeout (See RFC 1122 4.2.3.6 regarding keep alives, which would also > not cause HS loss, since the OS will respond to the probe). > > There may be certain broken middleboxes (loadbalancers etc) that stomp > on long idle TCP connections, but anyone that is running a control port > connection through such a thing, and sending RSA keying material in the > clear, probably has bigger things to worry about. > > > This also put quite a requirement on the user side to add an HS on its > > tor-ramdisk for instance but has to use a client that keeps the > > control connection opens for its lifetime?... How does that work with > > stem, it would have to keep the control connection open and the > > script using it can't quit else the socket gets closed by the OS? > > Yup, I don't see "you need to leave stem running" as being all that > bad, since this is mostly targeted at managed applications > (chat, filesharing, global leaks, etc). > > If someone has a suggestion for an alternative interface that can > handle applications crashing (possibly before they persist the list of > HSes they need to clean up), applications that are just poorly written > (and not cleaning up all the ephemeral HSes), and (optionally, though > lacking this would be a reduction in features) limiting cross > application HS enumeration, I'd be more inclined to change things.
First, thanks for doing this! I think it's a great feature which will make it much easier to create new hidden service applications. I like the idea of tying HS lifetime to the control port connection for the reasons you state, namely that cleanup is automatic when applications crash. However, it seems like in the case of applications which are not HS-specific this will necessitate keeping another process running just to keep the HS alive. I'd rather see two modes: one as you describe, and another in which the ephemeral HS stays running until a new control port connection requests that it be stopped. To avoid allowing enumeration of running services, the "stop" command could require that the requestor already knows some details of the HS - either a cookie generated at creation time, or perhaps just the private key that was provided when it was started. This of course wouldn't result in crashed applications' HSes being cleaned up automatically, but having a few stale HSes sitting around isn't the end of the world. One approach for cleaning them up could be that tor could remove them automatically after it sees connection refused a few times. ~leif _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
